> I think it must be compiled 64-bit, or he'd not be able to get > shared_buffers that high to start with. However, it's possible that the > postmaster's been started under a ulimit setting that constrains each > backend to just a few hundred meg of per-process memory.
Here's the output of ulimit -a by the "postgres" user the database is running under: [postg...@170226-db7 ~]$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited max nice (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 139264 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 max rt priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 139264 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited I think this means it does not have an artificial memory limit imposed, but is there a specific setting beyond these I could check do you think? Regards, Matt -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
