Kevin Brown <kevin@sysexperts.com> writes:
> Tom Lane wrote:
>> I'm imagining repeatedly open() until
>> failure at some point during postmaster startup, and then save that
>> result as the number-of-openable-files limit.
> I strongly favor this method. In particular, the probe should probably
> be done after all shared libraries have been loaded and initialized.
Don't think we can postpone it that long; fd.c is a pretty basic
facility. In any case, what of shared libraries opened after postmaster
startup?
I was thinking a bit yesterday about how to account for open files
chewed up by shared libraries. A simplistic solution is just to
decrease the fd.c limit by one each time we LOAD a new shlib. (The
subroutine to do this could presumably be called by the shlib, too,
if it had its own requirements for permanently-open files.) However,
that doesn't account for shared libraries that get pulled in indirectly.
For instance, loading pltcl.so probably pulls in libtcl.so. How could
we detect that? Is it worth repeating the open-till-fail exercise every
time we load a shlib? (Seems like not, and anyway there are stability
issues if multiple backends decide to do that in parallel.)
> I originally thought that each shared library that was loaded would eat
> a file descriptor (since I thought it would be implemented via mmap())
> but that doesn't seem to be the case, at least under Linux
Hmm. This may be OS-specific. The shlibs certainly show up in the
output of lsof in every variant I've checked, but do they count against
your open-file limit?
regards, tom lane
