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

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

"David Parker" <dparker@tazznetworks.com> writes:

OK, well that's good to know. You mentioned ulimit in
http://archives.postgresql.org/pgsql-bugs/2003-12/msg00080.php

Well, that was a different scenario --- or at least I thought it was.
Are you seeing unwanted shutdown of the entire database cluster, or just
an individual backend? What shows up in the postmaster log when this
happens?

regards, tom lane

It's just an individual backend. Unfortunately I don't have the postgres
log file yet, which would obviously help - I only have the application
client's log, but the people reporting the problem know they need to get
me the database log file next time it happens. I haven't been able to
repro this on my own yet.

Thanks.

- DAP