RE: "wal receiver" process hang in syslog() while exiting after receiving SIGTERM while the postgres has been promoted.

Hi,
Well, if you agree with do not write log in signal handling function in any circumstance? I see in many cases in postgresql signal handling function just set one flag which triggers its main process to handling the progress.
How about simply remove the code lines?

--- walreceiver_old.c
+++ walreceiver.c
@@ -816,10 +816,6 @@

SetLatch(&WalRcv->latch);

- /* Don't joggle the elbow of proc_exit */
- if (!proc_exit_inprogress && WalRcvImmediateInterruptOK)
- ProcessWalRcvInterrupts();
-
errno = save_errno;
}

Br. ☺
Chen Yan(Jack)

-----Original Message-----
From: Robert Haas [mailto:robertmhaas(at)gmail(dot)com]
Sent: Friday, June 22, 2018 8:51 PM
To: Chen, Yan-Jack (NSB - CN/Hangzhou) <yan-jack(dot)chen(at)nokia-sbell(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: "wal receiver" process hang in syslog() while exiting after receiving SIGTERM while the postgres has been promoted.

On Thu, Jun 21, 2018 at 1:11 AM, Chen, Yan-Jack (NSB - CN/Hangzhou)
<yan-jack(dot)chen(at)nokia-sbell(dot)com> wrote:
> Hi Hackers,
> We encounter one problem happened while we try to promote standby
> postgres(version 9.6.9) server to active. From the trace(we triggered the
> process abort). We can see the process was hang in syslog() while handling
> SIGTERM. According to below article. Looks it is risky to write syslog in
> signal handling. Any idea to avoid it?

Huh. I thought that Andres had removed all of this kind of stuff back
in 6753333f55e1d9bcb9da4323556b456583624a07,
4f85fde8eb860f263384fffdca660e16e77c7f76, and
387da18874afa17156ee3af63766f17efb53c4b9, and related commits, but
rereading the commit message I see that it wasn't that ambitious.
Probably a similar approach would make sense here, though.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company