Re: pgsql: Add kqueue(2) support to the WaitEventSet API.

> Le 20 févr. 2020 à 12:15, Thomas Munro <thomas.munro@gmail.com> a écrit :
>
> On Thu, Feb 20, 2020 at 8:24 PM Michael Paquier <michael@paquier.xyz> wrote:
>> On Wed, Feb 05, 2020 at 04:59:10AM +0000, Thomas Munro wrote:
>>> Add kqueue(2) support to the WaitEventSet API.
>>>
>>> Use kevent(2) to wait for events on the BSD family of operating
>>> systems and macOS.  This is similar to the epoll(2) support added
>>> for Linux by commit 98a64d0bd.
>>
>> Worth noting this issue with the test suite of postgres_fdw for
>> buildfarm animal coypu, running on NetBSD:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=coypu&dt=2020-02-19%2023%3A01%3A01
>> +ERROR:  kqueue failed: Too many open files
>
> Hmm.  So coypu just came back after 48 days, and the new kqueue() code
> fails for process 19829 after successfully running 265 log lines'
> worth of  postgres_fdw tests, because it's run out of file
> descriptors.  I can see that WaitLatchOrSocket() actually could leak
> an epoll/kqueue socket if WaitEventSetWait() raises an error, which is
> interesting, but apparently not the explanation here because we don't
> see a preceding error report.  Another theory would be that this
> machine has a low max_safe_fds, and NUM_RESERVED_FDS is only just
> enough to handle the various sockets that postgres_fdw.sql creates and
> at some point kqueue()'s demand for just one more pushed it over the
> edge.  From the error text and a look at the man page for errno, this
> error is EMFILE (per process limit, which could be as low as 64)
> rather then ENFILE (system limit).
>
> Remi, any chance you could run gmake installcheck under
> contrib/postgres_fdw on that host, to see if this is repeatable?  Can
> you tell us about the relevant limits?  Maybe ulimit -n (for the user
> that runs the build farm), and also sysctl -a | grep descriptors,
> sysctl -a | grep maxfiles?


Hi,

Unfortunalty, coypu went offline again. I will run tests as soon as I can bring it back up.

Rémi