RE: SIGQUIT handling, redux - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: SIGQUIT handling, redux
Date
Msg-id TYAPR01MB299062483CF0D6115B6918B5FE270@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: SIGQUIT handling, redux  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
From: Tom Lane <tgl@sss.pgh.pa.us>
> This is straying a bit from the stated topic of this thread, but ...
> I did some further looking around to see whether there were any
> unsafe signal handlers besides SIGQUIT ones.  The situation is not
> too awful, but I did find several issues not already mentioned
> in this thread:

Wow, your eyes catch this many issues.  (I was just wondering about one or two of them.)

I'm not sure if this is related, but I had been wondering if the following can be what it is now.


(1)
When logical replication is used, pg_ctl stop with the default fast mode emits the message about termination of logical
replicationlauncher.  Although it's not FATAL or ERROR, but I was a bit startled when I saw this message for the first
time. Why should this message be emitted while nothing about other postmaster children are reported?  The logical rep
launcherignores SIGINT (SIG_IGN). 

LOG:  received fast shutdown request
LOG:  aborting any active transactions
LOG:  background worker "logical replication launcher" (PID 10056) exited with exit code 1
LOG:  shutting down
LOG:  database system is shut down


(2)
When the physical standby stops, a FATAL message is output.  It may be annoying to the DBA that monitors messages with
highseverity. 

LOG:  received fast shutdown request
LOG:  aborting any active transactions
FATAL:  terminating walreceiver process due to administrator command
LOG:  shutting down
LOG:  database system is shut down


(3)
When WaitLatch(EXIT_ON_POSTMASTER_DEATH) detects postmaster death, it calls proc_exit(1).  Can we call _exit(1) here
likewise?


Regards
Takayuki Tsunakawa





pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Division in dynahash.c due to HASH_FFACTOR
Next
From: Craig Ringer
Date:
Subject: Proposals for making it easier to write correct bgworkers