OK, well that's good to know. You mentioned ulimit in
http://archives.postgresql.org/pgsql-bugs/2003-12/msg00080.php
which ulimit parameters were you thinking of? That post is what set me
barking up
this tree ;-) The only other thing not set to "unlimited" is stack,
which is set to
8480 for the database owner on this system (not sure where that number
came from).
Thanks.
- DAP
>-----Original Message-----
>From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>Sent: Friday, February 11, 2005 6:17 PM
>To: David Parker
>Cc: pgsql-general@postgresql.org
>Subject: Re: [GENERAL] file descriptors
>
>"David Parker" <dparker@tazznetworks.com> writes:
>> We have started getting the error
>> FATAL: terminating connection due to administrator
>command in some
>> of our processes. Searching in the archives, I gather that this is
>> caused by a SIGTERM, and might be coming from a ulimit problem.
>
>It is coming from a SIGTERM, but I'm not aware of any
>platforms that respond to exceeding the ulimit open-files
>limit by SIGTERM'ing the process. I think you're barking up
>the wrong tree.
>
>> We are running Solaris 9/Intel, and the ulimit for nofiles for the
>> database owner process is 256. I suspect this needs to be set to
>> "unlimited", which I don't think should cause a problem on
>Solaris (?).
>
>I think it *would* cause a problem, unless Solaris can support
>unlimited numbers of open files --- we have certainly seen PG
>eat all available file table slots on other kernels. I don't
>recommend raising nofiles.
>The backends are perfectly capable of working within the
>nofiles limit you set, and 256 seems high enough to avoid thrashing.
>
> regards, tom lane
>