Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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:01:19Z
Lists: pgsql-hackers
Hi, On 2020-02-24 16:14:53 -0300, Alvaro Herrera wrote: > But the C runtime does: > https://docs.microsoft.com/en-us/cpp/c-runtime-library/file-handling?view=vs-2019 > 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. Perhaps it'd even be worthwhile to just always raise the limit, if possible, in set_max_safe_fds(), by max_safe_fds + NUM_RESERVED_FDS. That way PLs, other shared libs, would have a more usualy amount of FDs available. Rather than a fairly small number, but only when the backend has been running for a while in the right workload. Greetings, Andres Freund
Commits
-
Don't use EV_CLEAR for kqueue events.
- 9b8aa0929390 13.0 cited
-
Fix kqueue support under debugger on macOS.
- 7bc84a1f304a 13.0 landed
-
Account explicitly for long-lived FDs that are allocated outside fd.c.
- 3d475515a15f 13.0 landed
-
Add kqueue(2) support to the WaitEventSet API.
- 815c2f0972c8 13.0 cited
-
Introduce WaitEventSet API.
- 98a64d0bd713 9.6.0 cited