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@xxxxxxxxxxxxx] >Sent: Friday, February 11, 2005 6:17 PM >To: David Parker >Cc: pgsql-general@xxxxxxxxxxxxxx >Subject: Re: file descriptors > >"David Parker" <dparker@xxxxxxxxxxxxxxxx> 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 > ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
