Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Thomas Munro <thomas.munro@gmail.com>, Rémi Zara <remi_zara@mac.com>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-02-24T20:07:37Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On 2020-02-24 16:14:53 -0300, Alvaro Herrera wrote:
>> I suppose we do use the C runtime.  There's a reference to
>> _setmaxstdio() being able to raise the limit from the default of 512 to
>> up to 8192 open files.  We don't currently invoke that.
>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setmaxstdio?view=vs-2019

> If we ever go for that, we should also consider raising the limit on
> unix systems up to the hard limit when hitting the fd ceiling. I.e. get
> the current limit with getrlimit(RLIMIT_NOFILE) and raise rlim_cur
> [closer] to rlim_max with setrlimit.

I'm disinclined to think we should override the user's wishes in this way.
Especially given PG's proven ability to run the kernel completely out of
file descriptors ...

			regards, tom lane

Commits

  1. Don't use EV_CLEAR for kqueue events.

  2. Fix kqueue support under debugger on macOS.

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

  4. Add kqueue(2) support to the WaitEventSet API.

  5. Introduce WaitEventSet API.