[pgpool-hackers: 3900] sigusr1_interrupt_processor() does not process all pending requests

[Tatsuo Ishii]

sigusr1_interrupt_processor() is a routine used by watchdog. When a
process sends SIGUSR1 signal to the parent pgpool process, it
associates the request details in an array in the shared memory.

typedef enum
{
	SIG_FAILOVER_INTERRUPT,		/* signal main to start failover */
	SIG_WATCHDOG_STATE_CHANGED, /* notify main about local watchdog node state
								 * changed */
	SIG_BACKEND_SYNC_REQUIRED,	/* notify main about local backend state sync
								 * required */
	SIG_WATCHDOG_QUORUM_CHANGED,	/* notify main about cluster quorum change
									 * of watchdog cluster */
	SIG_INFORM_QUARANTINE_NODES, /* notify main about send degenerate requests
								 * for all quarantine nodes */
	MAX_INTERRUPTS				/* Must be last! */
}			User1SignalReason;


typedef struct User1SignalSlot
{
	sig_atomic_t signalFlags[MAX_INTERRUPTS];
}			User1SignalSlot;

And sigusr1_interrupt_processor() is called in the initialize phase
and while SIGUSR1 is fired.

#define CHECK_REQUEST \
	do { \
		if (wakeup_request) \
		{ \
			wakeup_children(); \
			wakeup_request = 0; \
		} \
		if (sigusr1_request) \
		{ \

Looking into the code of sigusr1_interrupt_processor(), it seems
sigusr1_interrupt_processor() is assumed that it processes all the
request details in sigalFlags array even if there are multiple details
in the array. But actually it's not. I have added a small routine to
verify whether non processed value remains in the array and ran
regression test 18. It appeared that after execution of
sigusr1_interrupt_processor() still the array holds remaining pending
request:

t-ishii$ grep signalFlags pgpool[0-2]/log/pgpool.log
pgpool1/log/pgpool.log:2021-05-18 15:25:58: main pid 12696: LOG:  signalFlags: 3 is true
pgpool2/log/pgpool.log:2021-05-18 15:25:58: main pid 12700: LOG:  signalFlags: 3 is true
pgpool2/log/pgpool.log:2021-05-18 15:26:04: main pid 12700: LOG:  signalFlags: 3 is true

Note that "3" is SIG_WATCHDOG_QUORUM_CHANGED.

I don't know if this actually gives some bad effects to pgpool or not
but I think at least we need to confirm that.

Comments?

Patch for the test attached.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: check.diff
Type: text/x-patch
Size: 1504 bytes
Desc: not available
URL: <http://www.pgpool.net/pipermail/pgpool-hackers/attachments/20210518/6cd03ba3/attachment.bin>