選擇“ ..創建表期間”的Postgresql 9.1內存不足。

Question

我在Ubuntu Linux 11和Postgresql 9.1上。 我在dblink上使用CREATE TABLE .. SELECT，並得到約200萬行的表

ERROR:  out of memory
DETAIL:  Failed on request of size 432.

因此，我要從一個數據庫中獲取整個表的內容，然后將其插入（或創建）到另一個數據庫中（在同一台機器上）。 我使用的是Postgresql的默認值，但是我也嘗試了pgtune的值，但無濟於事。 在插入期間，我確實看到內存使用率上升，但是在達到我的計算機限制之前發生了錯誤。 ulimit -a說

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 30865
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 30865
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

如果我確實將表創建為...在同一個數據庫中進行選擇，那么它將正常工作。 有任何想法嗎？

編輯：我嘗試調整postgresql.conf中的各種內存設置，但沒有幫助。 我想念什么？

Answer 1

我的猜測是，中間集僅分配給內存，本身無法實現。 最好的選擇是找到解決方法或與dblink人員合作以糾正此問題。 一些潛在的解決方法是：

1. 使用COPY創建一個csv文件，並將其插入到數據庫中。

2. 將查詢分塊，一次說10萬行。

明確地說，我的猜測是dblink通過分配結果集，分配所需的內存以及將數據傳遞到Postgresql來處理事務。 可能這樣做的方式是，當請求未完全分配在dblink模塊本身的內存中時，可以使請求快速被代理（並通過網絡連接傳輸）。

但是，對於INSERT ... SELECT它可能首先是在內存中分配整個結果集，然后嘗試對其進行處理並將其立即插入表中。

但這是一種直覺，沒有對代碼進行詳細的檢查（我確實打開了dblink.c並迅速對其進行了掃描）。 您在這里必須記住，PostgreSQL同時充當另一台服務器的數據庫客戶端和數據庫服務器本身，因此libpq和后端的內存陷阱將合並在一起。

編輯：經過更多的審查，看起來這似乎是正確的。 dblink在內部使用游標。 我的猜測是在插入之前從游標中獲取了所有內容，因此可以立即進行操作。