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?
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.
--
Thomas Munro
http://www.enterprisedb.com