Tom Lane wrote:
Geoffrey <esoteric@xxxxxxxxxxxx> writes:
Alvaro Herrera wrote:
Yes. Which is kinda weird, because Postgres actually tests the number
when it starts, so that if you set the number too high, it will decrease
it according to what the kernel allows.
Maybe the test is newer than the version you are running -- what was it,
again?
7.4.13
Hmph ... 7.4.13 does have the same set_max_safe_fds() logic as HEAD.
So this shouldn't be happening really, no matter what the relative
values of max_files_per_process and ulimit -n are.
Explanations I can think of:
* ulimit -n decreased after process startup (is this even possible?)
* something is leaking file descriptors that are outside fd.c's control,
such that eventually there are more than NUM_RESERVED_FDS of 'em.
Theory B seems a lot more plausible. It'd be interesting to look at
"lsof" output for one of the backend processes that is emitting this
message, to see if we can identify what's getting leaked.
We have been looking at a particular issue related to a library we've
built into the backend. It does appear that this library could well be
the culprit. We are researching it further, will post more as we get
more info.
--
Until later, Geoffrey
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin
