Horton

Re: Using WaitEventSet in the postmaster

Thomas Munro <thomas.munro@gmail.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-12-02T21:41:36Z
Lists: pgsql-hackers

Attachments

On Fri, Dec 2, 2022 at 3:36 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Fri, Dec 2, 2022 at 2:40 PM Andres Freund <andres@anarazel.de> wrote:
> > It doesn't seem trivial (but not impossible either) to make SetLatch() robust
> > against arbitrary corruption. So it seems easier to me to just put the latch
> > in process local memory, and do a SetLatch() in postmaster's SIGUSR1 handler.
>
> Alright, good idea, I'll do a v2 like that.

Here's an iteration like that.  Still WIP grade.  It passes, but there
must be something I don't understand about this computer program yet,
because if I move the "if (pending_..." section up into the block
where WL_LATCH_SET has arrived (instead of testing those variables
every time through the loop), a couple of tests leave zombie
(unreaped) processes behind, indicating that something funky happened
to the state machine that I haven't yet grokked.  Will look more next
week.

By the way, I think if we do this and then also do
s/select(/WaitLatchOrSocket(/ in auth.c's RADIUS code, then we could
then drop a chunk of newly unreachable code in
src/backend/port/win32/socket.c (though maybe I missed something; it's
quite hard to grep for "select" in a SQL database :-D).  There's also
a bunch of suspect stuff in there about UDP that is already dead
thanks to the pgstats work.

Commits

  1. Remove unneeded volatile qualifiers from postmaster.c.

  2. Fix WaitEventSetWait() buffer overrun.

  3. Refactor DetermineSleepTime() to use milliseconds.

  4. Use WaitEventSet API for postmaster's event loop.

  5. Allow parent's WaitEventSets to be freed after fork().

  6. Don't leak a signalfd when using latches in the postmaster.

  7. Add WL_SOCKET_ACCEPT event to WaitEventSet API.

  8. From: Phil Thompson <phil@river-bank.demon.co.uk>