Re: Misleading "epoll_create1 failed: Too many open files"

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2024-11-26T17:21:21Z
Lists: pgsql-hackers

Attachments

Hi,

On 2024-11-26 11:35:56 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I think it's rather confusing to claim that epoll_create1() failed when we
> > didn't even call it.
> > Why are we misattributing the failure to a system call that we didn't make?
> 
> I think the idea was that this mechanism is equivalent to an EMFILE
> limit.  But if you feel a need to make a distinction, this seems fine:
> 
> >                 elog(ERROR, "AcquireExternalFD, for epoll_create1, failed: %m");
> 
> You should probably check all of 3d475515a, because I think
> I applied the same idea in more than one place.

Yea, there's another equivalent message for kqueue a few lines below.

The commit also added uses of AcquireExternalFD() to dblink and postgres_fdw (
since migrated to libpq-be-fe-helpers.h), but I don't think those need
improving in the same way. They never made it sound like it was a syscall
itself failing.

Greetings,

Andres Freund

Commits

  1. Distinguish between AcquireExternalFD and epoll_create1 / kqueue failing

  2. Account explicitly for long-lived FDs that are allocated outside fd.c.