Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe perprocess

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe perprocess
Дата
Msg-id 20180719.193054.155432744.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Mai Peng
Дата:
Сообщение: Re: Segfault logical replication PG 10.4
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: Make foo=null a warning by default.