Alvaro Herrera <alvherre@commandprompt.com> writes:
> Maybe we should have another inter-backend signal: when a process gets
> ENFILE, signal all other backends and they close a bunch of files each.
I was wondering about that myself, but on balance I think it'd be a lot
of work to achieve not much. What you would have is that Postgres would
ramp its FD usage up to hit the kernel limit, things outside the
database would fail for some period of time, then a backend would get
ENFILE and we'd cut down our FD usage. Lather, rinse, repeat, ad
infinitum. You'd have intermittent hard-to-reproduce failures of every
other service on the box; and you'd *still* be at risk of the DB
crashing, if walwriter or another low-cushion process hit the problem
first.
The only really reliable setup is to have max_connections times
max_files_per_process less than the kernel limit. If we do something to
mask the problem when it happens, I don't think we're doing the DBA a
service in the long run.
Thought: it's probably possible to find out the kernel limit on many
platforms. Maybe postmaster startup should try to get that limit, and
print an annoying warning if it's less than max_connections times
max_files_per_process plus some safety factor?
regards, tom lane
