Re: kevent latch paths don't handle postmaster death well

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: kevent latch paths don't handle postmaster death well
Date: 2020-10-14 23:55:19
Message-ID: CA+hUKG+mbvd5C3hz-K_0YMYsJdGRazsZKpAgoB-UUcZtgZcvmQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 15, 2020 at 12:14 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2020-10-15 11:10:28 +1300, Thomas Munro wrote:
> >> I don't think that's a problem -- the kernel will report the event to
> >> each interested kqueue object. The attached fixes the problem for me.
>
> > Will it do so even if the kqueue is created after postmaster death?
>
> I did not try to test it, but there's code that purports to handle that
> in latch.c, ~ line 1150, and the behavior it's expecting mostly agrees
> with what I read in the macOS kevent man page. One thing I'd suggest

Yep, I did handle the obvious races here.

> is that EACCES probably needs to be treated as "postmaster already dead",
> too, in case the PID is now owned by another user ID.

Good point. I'll push that change later today.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-10-15 00:25:23 Re: speed up unicode decomposition and recomposition
Previous Message Alvaro Herrera 2020-10-14 23:16:27 pgsql: Restore replication protocol's duplicate command tags