From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Rémi Zara <remi_zara@mac.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
Date: Thu, 20 Feb 2020 14:56:57 -0500
Message-ID: <20263.1582228617@sss.pgh.pa.us> (raw)
In-Reply-To: <19710.1582227844@sss.pgh.pa.us>
References: <E1izCmM-0005pV-Co@gemulon.postgresql.org>
<20200220072435.GM2288@paquier.xyz>
<CA+hUKG+yGQDPdwcH5euDb_pE7OcnbrvGDLoOi2JMaCwj4G+ttg@mail.gmail.com>
<08364CCB-07F5-423E-8CE0-ABF0195C4CA2@mac.com>
<17106.1582224047@sss.pgh.pa.us>
<19710.1582227844@sss.pgh.pa.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, thomas.munro@gmail.com, remi_zara@mac.com, michael@paquier.xyz, pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
In-Reply-To: <20263.1582228617@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox