Tom Lane wrote:
> Geoffrey <esoteric@3times25.net> 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
