On 2017-08-07 17:05:06 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-08-07 16:52:42 -0400, Tom Lane wrote: > >> No, I don't think so. If you're depending on the NUM_RESERVED_FDS > >> headroom for anything meaningful, *you're doing it wrong*. You should be > >> getting an FD via fd.c, so that there is an opportunity to free up an FD > >> (by closing a VFD) if you're up against system limits. Relying on > >> NUM_RESERVED_FDS headroom can only protect against EMFILE not ENFILE. > > > How would this work for libpq based stuff like postgres fdw? Or some > > random PL doing something with files? There's very little headroom here. > > Probably the best we can hope for there is to have fd.c provide a function > "close an FD please", which postgres_fdw could call if libpq fails because > of ENFILE/EMFILE, and then retry.
Unless that takes up a slot in fd.c while in use, that'll still leave us open to failures to open files in some critical parts, unless I miss something. And then we'd have to teach similar things to PLs etc. I agree that having some more slop isn't a proper solution, but only having ~30 fds as slop on the most common systems seems mightily small. > (Though I'm unsure how reliably postgres_fdw can detect that failure > reason right now --- I don't know that we preserve errno on the way > out of PQconnect.) Yea, probably not really... Regards, Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
