Alvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
