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:05:25 |
Message-ID: | 51543.192.168.1.106.1234163125.squirrel@msqr.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> 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:
[postgres(at)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-02-09 07:06:53 | Re: Out of memory on SELECT in 8.3.5 |
Previous Message | Matt Magoffin | 2009-02-09 07:01:24 | Re: Out of memory on SELECT in 8.3.5 |