Thanks for the explanation on the ulimits; I can see how that could turn out a problem in some cases.
Following Tom's suggestion, here is the startup script I used:
#!/bin/sh
ulimit -a > $PGHOST/server.ulimit
pg_ctl start -l $PGHOST/server.log
The ulimits seem to be the same, though:
$> cat server.ulimit
core file size (blocks, -c) 100000000
data seg size (kbytes, -d) unlimited
max nice (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) unlimited
max rt priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
Regards,
Michael A.
Tom Lane wrote:
Andrew Sullivan <ajs@crankycanuck.ca> writes:
On Tue, Jan 08, 2008 at 05:27:16PM +0100, Michael Akinde wrote:
Those are the ulimits of the db_admin account (i.e., the user that set
up and runs the DB processes). Is Postgres limited by other settings?
On one system I used many years ago, /bin/sh wasn't what I thought it was,
and so the ulimit that I got when logged in was not what the postmaster was
starting under. Took me many days to figure out what was up.
The only thing I find convincing is to insert "ulimit -a >someplace"
into the script that starts the postmaster, adjacent to where it does
so, and then reboot. There are too many systems on which daemons are
launched under settings different from what interactive shells use
(a policy that's often a good one, too).
regards, tom lane
