Re: VACUUM FULL out of memory

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(at)crankycanuck(dot)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
>