Re: Out of memory on SELECT in 8.3.5

From: "Matt Magoffin" <postgresql(dot)org(at)msqr(dot)us>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Stephen Frost" <sfrost(at)snowman(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: Out of memory on SELECT in 8.3.5
Date: 2009-02-09 07:56:30
Message-ID: 51651.192.168.1.106.1234166190.squirrel@msqr.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> Agreed, that ulimit isn't reflecting any such limit, but is that really
> the same environment the postmaster gets started in? I wouldn't trust
> a system startup script to be launched in the same environment that a
> login shell gets. You might try adding
> ulimit -a >/tmp/something
> to the startup script to find out for sure.

Our startup script is calling

su -l postgres ...

So I thought the limits would be the same (from the -l flag)? I then tried
to mimic this with the following:

[root(at)170226-db7 ~]# su -l postgres -c "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

which I think should accurately reflect what the postmaster environment
should be seeing.

Regards,
Matt

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Stephen Frost 2009-02-09 07:59:36 Re: Out of memory on SELECT in 8.3.5
Previous Message Matt Magoffin 2009-02-09 07:50:58 Re: Out of memory on SELECT in 8.3.5