Re: Out of file-descriptors message

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Geoffrey <esoteric(at)3times25(dot)net>
Cc: John Allgood <john(at)turbocorp(dot)com>, pgsql-admin(at)postgresql(dot)org, Terry Lee Tucker <terry(at)leetuckert(dot)net>, "J(dot) D(dot) Pearson" <jpearson(at)turbocorp(dot)com>
Subject: Re: Out of file-descriptors message
Date: 2006-11-30 15:30:27
Message-ID: 13454.1164900627@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Geoffrey <esoteric(at)3times25(dot)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

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Geoffrey 2006-11-30 15:40:36 Re: Out of file-descriptors message
Previous Message Geoffrey 2006-11-30 15:29:19 Re: Out of file-descriptors message