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.
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 |