Re: Using WaitEventSet in the postmaster - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Using WaitEventSet in the postmaster
Date
Msg-id CA+hUKGJ6eMMvcOMO-Ess6uAbRvzXbzkExz5oq8=0vPRB6sUFFg@mail.gmail.com
Whole thread Raw
In response to Re: Using WaitEventSet in the postmaster  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Using WaitEventSet in the postmaster  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
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.

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Error-safe user functions
Next
From: Peter Smith
Date:
Subject: Fwd: Perform streaming logical transactions by background workers and parallel apply