Hi,
Well, if you agree with do not write log in signal handling function in any circumstance? I see in many cases in
postgresqlsignal 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@gmail.com]
Sent: Friday, June 22, 2018 8:51 PM
To: Chen, Yan-Jack (NSB - CN/Hangzhou) <yan-jack.chen@nokia-sbell.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.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.chen@nokia-sbell.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