Re: Using WaitEventSet in the postmaster

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Using WaitEventSet in the postmaster
Date: 2022-12-05 09:45:57
Message-ID: CA+hUKG+sCqnqxUq3KAyiVAqAfWVFr3HcKYXG1S5EbaNKOzZt4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Dec 3, 2022 at 10:41 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> 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.

Duh. The reason for that was the pre-existing special case for
PM_WAIT_DEAD_END, which used a sleep(100ms) loop to wait for children
to exit, which I needed to change to a latch wait. Fixed in the next
iteration, attached.

The reason for the existing sleep-based approach was that we didn't
want to accept any more connections (or spin furiously because the
listen queue was non-empty). So in this version I invented a way to
suppress socket events temporarily with WL_SOCKET_IGNORE, and then
reactivate them after crash reinit.

Still WIP, but I hope travelling in the right direction.

Attachment Content-Type Size
v3-0001-Give-the-postmaster-a-WaitEventSet-and-a-latch.patch text/x-patch 28.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-12-05 09:56:31 Re: doc: add missing "id" attributes to extension packaging page
Previous Message Daniel Gustafsson 2022-12-05 09:42:38 Marking options deprecated in help output