| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, 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:14:35 |
| Message-ID: | 3638494.1602717275@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
is that EACCES probably needs to be treated as "postmaster already dead",
too, in case the PID is now owned by another user ID.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2020-10-14 23:16:27 | pgsql: Restore replication protocol's duplicate command tags |
| Previous Message | Andres Freund | 2020-10-14 22:59:42 | Re: kevent latch paths don't handle postmaster death well |