無效的內存的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

回答

相關問題