Re: max_files_per_processes vs others uses of file descriptors

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2017-08-07 17:05:06 -0400, Tom Lane wrote:
>> 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.

Well, there's always a race condition there, in that someone else can
eat the kernel FD as soon as you free it. That's why we do this in a
retry loop.

> 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.

Meh. The lack of field complaints about this doesn't indicate to me that
we have a huge problem, and in any case, just increasing NUM_RESERVED_FDS
would do nothing for the system-wide limits.

regards, tom lane