Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commita0bbd01

Browse files
committed
Fix some minor postmaster-state-machine issues.
In sigusr1_handler, don't ignore PMSIGNAL_ADVANCE_STATE_MACHINE basedon pmState. The restriction is unnecessary (PostmasterStateMachineshould work in any state), not future-proof (since it makes too manyassumptions about why the signal might be sent), and broken even todaybecause a race condition can make it necessary to respond to the signalin PM_WAIT_READONLY state. The race condition seems unlikely, butif it did happen, a hot-standby postmaster could fail to shut downafter receiving a smart-shutdown request.In MaybeStartWalReceiver, don't clear the WalReceiverRequested flagif the fork attempt fails. Leaving it set allows us to tryagain in future iterations of the postmaster idle loop. (The startupprocess would eventually send a fresh request signal, but this changemay allow us to retry the fork sooner.)Remove an obsolete comment and unnecessary test inPostmasterStateMachine's handling of PM_SHUTDOWN_2 state. It's notpossible to have a live walreceiver in that state, and AFAICT has notbeen possible since commit5e85315. This isn't a live bug, but thefalse comment is quite confusing to readers.In passing, rearrange sigusr1_handler's CheckPromoteSignal tests so thatwe don't uselessly perform stat() calls that we're going to ignore theresults of.Add some comments clarifying the behavior of MaybeStartWalReceiver;I very nearly rearranged it in a way that'd reintroduce the racecondition fixed ine5d494d. Mea culpa for not commenting thatproperly at the time.Back-patch to all supported branches. The PMSIGNAL_ADVANCE_STATE_MACHINEchange is the only one of even minor significance, but we might as wellkeep this code in sync across branches.Discussion:https://postgr.es/m/9001.1556046681@sss.pgh.pa.us
1 parent7c02c3f commita0bbd01

File tree

1 file changed

+26
-11
lines changed

1 file changed

+26
-11
lines changed

‎src/backend/postmaster/postmaster.c‎

Lines changed: 26 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -3772,12 +3772,8 @@ PostmasterStateMachine(void)
37723772
* dead_end children left. There shouldn't be any regular backends
37733773
* left by now anyway; what we're really waiting for is walsenders and
37743774
* archiver.
3775-
*
3776-
* Walreceiver should normally be dead by now, but not when a fast
3777-
* shutdown is performed during recovery.
37783775
*/
3779-
if (PgArchPID==0&&CountChildren(BACKEND_TYPE_ALL)==0&&
3780-
WalReceiverPID==0)
3776+
if (PgArchPID==0&&CountChildren(BACKEND_TYPE_ALL)==0)
37813777
{
37823778
pmState=PM_WAIT_DEAD_END;
37833779
}
@@ -5168,16 +5164,25 @@ sigusr1_handler(SIGNAL_ARGS)
51685164
MaybeStartWalReceiver();
51695165
}
51705166

5171-
if (CheckPostmasterSignal(PMSIGNAL_ADVANCE_STATE_MACHINE)&&
5172-
(pmState==PM_WAIT_BACKUP||pmState==PM_WAIT_BACKENDS))
5167+
/*
5168+
* Try to advance postmaster's state machine, if a child requests it.
5169+
*
5170+
* Be careful about the order of this action relative to sigusr1_handler's
5171+
* other actions. Generally, this should be after other actions, in case
5172+
* they have effects PostmasterStateMachine would need to know about.
5173+
* However, we should do it before the CheckPromoteSignal step, which
5174+
* cannot have any (immediate) effect on the state machine, but does
5175+
* depend on what state we're in now.
5176+
*/
5177+
if (CheckPostmasterSignal(PMSIGNAL_ADVANCE_STATE_MACHINE))
51735178
{
5174-
/* Advance postmaster's state machine */
51755179
PostmasterStateMachine();
51765180
}
51775181

5178-
if (CheckPromoteSignal()&&StartupPID!=0&&
5182+
if (StartupPID!=0&&
51795183
(pmState==PM_STARTUP||pmState==PM_RECOVERY||
5180-
pmState==PM_HOT_STANDBY||pmState==PM_WAIT_READONLY))
5184+
pmState==PM_HOT_STANDBY||pmState==PM_WAIT_READONLY)&&
5185+
CheckPromoteSignal())
51815186
{
51825187
/* Tell startup process to finish recovery */
51835188
signal_child(StartupPID,SIGUSR2);
@@ -5504,6 +5509,14 @@ StartAutovacuumWorker(void)
55045509
/*
55055510
* MaybeStartWalReceiver
55065511
*Start the WAL receiver process, if not running and our state allows.
5512+
*
5513+
* Note: if WalReceiverPID is already nonzero, it might seem that we should
5514+
* clear WalReceiverRequested. However, there's a race condition if the
5515+
* walreceiver terminates and the startup process immediately requests a new
5516+
* one: it's quite possible to get the signal for the request before reaping
5517+
* the dead walreceiver process. Better to risk launching an extra
5518+
* walreceiver than to miss launching one we need. (The walreceiver code
5519+
* has logic to recognize that it should go away if not needed.)
55075520
*/
55085521
staticvoid
55095522
MaybeStartWalReceiver(void)
@@ -5514,7 +5527,9 @@ MaybeStartWalReceiver(void)
55145527
Shutdown==NoShutdown)
55155528
{
55165529
WalReceiverPID=StartWalReceiver();
5517-
WalReceiverRequested= false;
5530+
if (WalReceiverPID!=0)
5531+
WalReceiverRequested= false;
5532+
/* else leave the flag set, so we'll try again later */
55185533
}
55195534
}
55205535

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp