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-07 01:12:37
Message-ID: CA+hUKGLw+QFMpzTs4t84vUWQM-LWkv0Q67BVk0vBGvkpdUC7Yg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 7, 2022 at 12:12 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2022-12-07 00:58:06 +1300, Thomas Munro wrote:
> > One way to fix that for the epoll version is to EPOLL_CTL_DEL and
> > EPOLL_CTL_ADD, whenever transitioning to/from a zero event mask.
> > Tried like that in this version. Another approach would be to
> > (finally) write DeleteWaitEvent() to do the same thing at a higher
> > level... seems overkill for this.
>
> What about just recreating the WES during crash restart?

It seems a bit like cheating but yeah that's a super simple solution,
and removes one patch from the stack. Done like that in this version.

> > > This seems to hardcode the specific wait events we're waiting for based on
> > > latch.c infrastructure. Not really convinced that's a good idea.
> >
> > What are you objecting to? The assumption that the first socket is at
> > position 1? The use of GetNumRegisteredWaitEvents()?
>
> The latter.

Removed.

Attachment Content-Type Size
v5-0001-Add-WL_SOCKET_ACCEPT-event-to-WaitEventSet-API.patch text/x-patch 3.5 KB
v5-0002-Don-t-leak-a-signalfd-when-using-latches-in-the-p.patch text/x-patch 1.6 KB
v5-0003-Allow-parent-s-WaitEventSets-to-be-freed-after-fo.patch text/x-patch 2.1 KB
v5-0004-Give-the-postmaster-a-WaitEventSet-and-a-latch.patch text/x-patch 22.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2022-12-07 01:13:06 Re: Using WaitEventSet in the postmaster
Previous Message Justin Pryzby 2022-12-07 01:08:43 Re: Using WaitEventSet in the postmaster