Andres Freund <andres@anarazel.de> writes:
> These days there's a number of other consumers of
> fds. E.g. postgres_fdw, epoll, ... All these aren't accounted for by
> fd.c.
> Given how close max_files_per_process is to the default linux limit of
> 1024 fds, I wonder if we shouldn't increase NUM_RESERVED_FDS by quite a
> bit?
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.
What this means is that the epoll stuff needs to be tied into fd.c more
than it is now, but that's likely a good thing anyway; it would for
example provide a more robust way of ensuring we don't leak epoll FDs at
transaction abort.
regards, tom lane
