无效的内存的alloc请求大小1610613056 4.3.14.0

我有表“测试”，我与此查询创建：无效的内存的alloc请求大小1610613056 4.3.14.0

CREATE TABLE test 
(
    id bigint, 
    str1 timestamp without time zone, 
    str2 text, 
    str3 text 
);

创建表之后，我添加的数据：

INSERT INTO test VALUES (1, '2017-08-29 10:51:40.190913', 'gfsdfg1', 'sfgsdhgy1'); 
INSERT INTO test VALUES (2, '2016-08-29 10:51:40.190913', 'gfsdfg2', 'sfgsdhgy2'); 
INSERT INTO test VALUES (3, '2015-08-29 10:51:40.190913', 'gfsdfg3', 'sfgsdhgy3'); 
INSERT INTO test VALUES (4, '2014-08-29 10:51:40.190913', 'gfsdfg4', 'sfgsdhgy4'); 
INSERT INTO test VALUES (5, '2013-08-29 10:51:40.190913', 'gfsdfg5', 'sfgsdhgy5'); 
INSERT INTO test VALUES (6, '2012-08-29 10:51:40.190913', 'gfsdfg6', 'sfgsdhgy6'); 
INSERT INTO test VALUES (7, '2011-08-29 10:51:40.190913', 'gfsdfg7', 'sfgsdhgy7'); 
INSERT INTO test VALUES (8, '2010-08-29 10:51:40.190913', 'gfsdfg8', 'sfgsdhgy8'); 
INSERT INTO test VALUES (9, '2009-08-29 10:51:40.190913', 'gfsdfg9', 'sfgsdhgy9'); 
INSERT INTO test VALUES (10, '2008-08-29 10:51:40.190913', 'gfsdfg10', 'sfgsdhgy10'); 
INSERT INTO test VALUES (11, '2009-08-29 10:51:40.190913', 'gfsdfg11', 'sfgsdhgy11'); 
INSERT INTO test VALUES (12, '2015-08-29 10:51:40.190913', 'gfsdfg12', 'sfgsdhgy12'); 
INSERT INTO test VALUES (13, '2020-08-29 10:51:40.190913', 'gfsdfg13', 'sfgsdhgy13');

而且那么我们尝试我更新这个表，这样的查询：

UPDATE test SET 
    str1 = c.str1, 
    str2 = c.str2, 
    str3 = c.str3 
FROM (
    VALUES 
     (10, '2017-08-29 11:11:37'::timestamp without time zone, 'str2-10', 'str3-10'), 
     (11, '2017-08-29 11:11:37'::timestamp without time zone, 'str2-11', 'str3-11'), 
     (12, '2017-08-29 11:11:37'::timestamp without time zone, 'str2-12', 'str3-12'), 
     (13, '2017-08-29 11:11:37'::timestamp without time zone, 'str2-13', 'str3-13') 
) AS c (id, str1, str2, str3) 
WHERE c.id = test.id;

而且我得到了错误：

ERROR: invalid memory alloc request size 1610613056 (context 'ExecutorState') (mcxt.c:1069) (mcxt.c:477) (seg0 node03:40000 pid=113577) (cdbdisp.c:1322)

我该如何解决这个错误？

来源

2017-08-29 Gennadiy Ilyashenko

你使用的是什么版本的GPDB？

有几个已知的规划错误 - 这看起来像一个老的遗留规划问题。

你可以试试set optimizer=on;或关闭吗？

随着大内存分配大小，更有可能这是造成计划者爆炸的表的统计问题。

作为最佳做法，请每CREATE后跟一个ANALYZE。

ANALYZE表格然后再次运行查询。

来源

2017-08-29 14:23:19

我应该补充一点，我无法使用4.3.12+ –

来重现此问题您使用的是哪种版本的GPDB？对不起！ GreenPlum的版本： x86_64-unknown-linux-gnu上的PostgreSQL 8.2.15（Greenplum Database 4.3.14.0 build 1），由GCC编译gcc（GCC）4.4.2 2017年5月25日07:18:28编写的操作系统 OS ： CentOS Linux版本7.3.1611（核心）使用'set optimizer = on;'没有帮我解决我的问题。 –

如何打印ALL（！）配置以便与不同的系统进行比较？当我在不同的系统（三个lxd容器）上运行这些查询时，一切正常（行由新数据更新）。 OS和Greenplum的版本完全相同。 –

无效的内存的alloc请求大小1610613056 4.3.14.0

回答

相关问题