Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Rémi Zara <remi_zara@mac.com>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers@lists.postgresql.org
Date: 2020-02-20T19:56:57Z
Lists: pgsql-hackers
I wrote: > It seems fairly obvious now that I look at it, but: the epoll and kqueue > variants of CreateWaitEventSet are both *fundamentally* unsafe, because > they assume that they can always get a FD when they want one, which is > not a property that we generally want backend code to have. The only > reason we've not seen this before with epoll is a lack of testing > under lots-of-FDs stress. > The fact that they'll likely leak those FDs on subsequent failures is > another not-very-nice property. Hmmm ... actually, there's a third problem, which is the implicit assumption that we can have as many concurrently-active WaitEventSets as we like. We can't, if they depend on FDs --- that's a precious resource. It doesn't look like we actually ever have more than about two per process right now, but I'm concerned about what will happen as the usage of the feature increases. regards, tom lane
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