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.
regards, tom lane