Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: thomas(dot)munro(at)enterprisedb(dot)com
Cc: hlinnaka(at)iki(dot)fi, andres(at)anarazel(dot)de, Marco_Pfatschbacher(at)genua(dot)de, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process
Date: 2018-07-19 10:30:54
Message-ID: 20180719.193054.155432744.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Thu, 19 Jul 2018 16:58:30 +1200, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> wrote in <CAEepm=1R__sW-CTByAi+cFUXX8tJu8MTNdeQGZ4L-x5gZ4mxNA(at)mail(dot)gmail(dot)com>
> On Wed, Jul 18, 2018 at 8:30 PM, Kyotaro HORIGUCHI
> <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> > At Wed, 18 Jul 2018 14:02:47 +1200, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> wrote in <CAEepm=3t57KBxb90CTqnDZiSTnTq3jwxZUc0zaFDiaOkGQqNxA(at)mail(dot)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2018-07-19 10:37:39 Re: Make foo=null a warning by default.
Previous Message Mai Peng 2018-07-19 10:20:18 Re: Segfault logical replication PG 10.4