Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe perprocess - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe perprocess
Date
Msg-id 20180719.193054.155432744.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
At Thu, 19 Jul 2018 16:58:30 +1200, Thomas Munro <thomas.munro@enterprisedb.com> wrote in
<CAEepm=1R__sW-CTByAi+cFUXX8tJu8MTNdeQGZ4L-x5gZ4mxNA@mail.gmail.com>
> On Wed, Jul 18, 2018 at 8:30 PM, Kyotaro HORIGUCHI
> <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> > At Wed, 18 Jul 2018 14:02:47 +1200, Thomas Munro <thomas.munro@enterprisedb.com> wrote in
<CAEepm=3t57KBxb90CTqnDZiSTnTq3jwxZUc0zaFDiaOkGQqNxA@mail.gmail.com>
> >> Here are some of the places I had to add WL_EXIT_ON_PM_DEATH:
> >> gather_readnext(), shm_mq_send_bytes(), shm_mq_receive_bytes(),
> >> shm_mq_wait_internal(), ProcSleep(), ProcWaitForSignal(), pg_sleep(),
> >> pgfdw_get_result().
> >>
> >> Was it intentional that any of those places don't currently exit on
> >> postmaster vaporisation?
> >
> > I think that backends are supposed to complete running query even
> > if postmaster dies meanwhile and currently that seems
> > true. pgfdw_get_result seems to be following the policy. Perhaps
> > it's the same for all of the functions listed above.
> 
> Hmm.  Why wait any longer?  The cluster is broken.  Is there some
> correctness reason to defer shutdown in any of these places?

Well, please don't get me wrong. I don't object to backends' exit
on postmaster death, rather I'm for it. Maybe the idea of mine
came from somthing like this (perhaps newer one), in the meaning
of just why it is working in that way now.

https://www.postgresql.org/message-id/21877.1294946166@sss.pgh.pa.us

> While looking for earlier discussion that might explain why some
> places ignored it, I came across this email from Andres, saying the
> same thing.
> 
> https://www.postgresql.org/message-id/20160321093534.inkduxvpirs5n44j%40alap3.anarazel.de
> 
> He mentioned that syslogger.c is a special case.  In my patch I added
> WL_EXIT_ON_PM_DEATH to SysLoggerMain()'s WaitLatch*() calls, because I
> have to or the new assertion fails.  Hmm, yeah, that's not great
> because it might discard the last words of other backends.  So here is
> a new version that treats syslogger.c specially and may have other
> performance benefits.

Yeah. That seems good. Couldn't we reuse prepared WaitEventSet in
other places? For example PgstatCollectorMain has the same
characteristics, where WaitLatchOrSocket is used with fixed
parameters and waiting on a socket which gets frequent receipts.

# Is it intentional that the patch doesn't touch pgstat.c?

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Mai Peng
Date:
Subject: Re: Segfault logical replication PG 10.4
Next
From: Fabien COELHO
Date:
Subject: Re: Make foo=null a warning by default.