Re: VACUUM FULL out of memory - Mailing list pgsql-hackers

From Michael Akinde
Subject Re: VACUUM FULL out of memory
Date
Msg-id 4784A6D9.8050904@met.no
Whole thread Raw
In response to Re: VACUUM FULL out of memory  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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 

Attachment

pgsql-hackers by date:

Previous
From: "Gokulakannan Somasundaram"
Date:
Subject: Some ideas about Vacuum
Next
From: Markus Schiltknecht
Date:
Subject: Re: Some ideas about Vacuum