我在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中的各种内存设置，但没有帮助。我错过了什么？
答案 0 :(得分：0)
我的猜测是，中间集只被分配给内存，本身无法实现。您最好的选择是找到解决方法或与dblink人员一起解决此问题。一些可能的解决方法是：
使用COPY创建csv文件并将其插入数据库。
将查询分块，一次说出100k行。
要清楚，我的猜测是dblink通过分配结果集，分配所需内存以及将数据传递给Postgresql来处理事情。有可能这样做可以让请求在dblink模块本身的内存中完全分配时，快速代理请求（并通过网络连接传输）。
然而对于INSERT ... SELECT，它可能首先在内存中分配整个结果集，然后尝试处理它并立即将其插入表中。
然而，如果没有详细的代码审查，这是一种直觉（我确实打开了dblink.c并快速扫描了它）。你必须要记住，PostgreSQL同时作为数据库客户端同时作为数据库服务器和数据库服务器本身，因此libpq和后端的内存都会聚集在一起。
编辑：经过多次审核后，看起来这大概是正确的。 dblink内部使用游标。我的猜测是在插入之前从光标中取出所有内容，这样它就可以立即进行操作。