1

我在 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

如果我确实在同一个数据库中创建表... select，那么它可以正常工作。有任何想法吗？

编辑：我尝试调整 postgresql.conf 中的各种内存设置，但没有帮助。我错过了什么？

4

1 回答 1

0

我的猜测是，中间集仅被分配给内存，本身无法实现。您最好的选择是找到解决方法或与 dblink 人员一起解决此问题。一些潜在的解决方法是：

  1. 使用 COPY 创建一个 csv 文件并将其插入到您的数据库中。

  2. 将查询分块说，一次 100k 行。

为了清楚起见，我的猜测是 dblink 通过分配结果集、分配所需内存并将数据交给 Postgresql 来处理事情。当请求可能没有完全分配在 dblink 模块本身的内存中时，这可能会以一种允许快速代理（并通过网络连接传输）的方式完成。

但是，INSERT ... SELECT它可能首先将整个结果集分配到内存中，然后尝试对其进行处理并将其立即插入表中。

然而，如果没有详细审查代码，这是一种直觉（我确实打开了 dblink.c 并快速扫描了它）。您必须在这里记住，PostgreSQL 同时充当另一台服务器的数据库客户端和数据库服务器本身，因此 libpq 和后端的内存陷阱将结合在一起。

编辑：经过多一点审查，这看起来大部分是正确的。dblink 在内部使用游标。我的猜测是在插入之前从游标中获取所有内容，因此它可以立即进行。

于 2013-04-06T16:05:21.540 回答