Re: Using WaitEventSet in the postmaster

On Fri, Dec 2, 2022 at 3:36 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Fri, Dec 2, 2022 at 2:40 PM Andres Freund <andres(at)anarazel(dot)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.