Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 985bd7d

Browse files
committed
Support clean switchover.
In replication, when we shutdown the master, walsender tries to send all the outstanding WAL records to the standby, and then to exit. This basically means that all the WAL records are fully synced between two servers after the clean shutdown of the master. So, after promoting the standby to new master, we can restart the stopped master as new standby without the need for a fresh backup from new master. But there was one problem so far: though walsender tries to send all the outstanding WAL records, it doesn't wait for them to be replicated to the standby. Then, before receiving all the WAL records, walreceiver can detect the closure of connection and exit. We cannot guarantee that there is no missing WAL in the standby after clean shutdown of the master. In this case, backup from new master is required when restarting the stopped master as new standby. This patch fixes this problem. It just changes walsender so that it waits for all the outstanding WAL records to be replicated to the standby before closing the replication connection. Per discussion, this is a fix that needs to get backpatched rather than new feature. So, back-patch to 9.1 where enough infrastructure for this exists. Patch by me, reviewed by Andres Freund.
1 parent 4f14c86 commit 985bd7d

File tree

1 file changed

+8
-4
lines changed

1 file changed

+8
-4
lines changed

src/backend/replication/walsender.c

Lines changed: 8 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -27,7 +27,8 @@
2727
* If the server is shut down, postmaster sends us SIGUSR2 after all
2828
* regular backends have exited and the shutdown checkpoint has been written.
2929
* This instruct walsender to send any outstanding WAL, including the
30-
* shutdown checkpoint record, and then exit.
30+
* shutdown checkpoint record, wait for it to be replicated to the standby,
31+
* and then exit.
3132
*
3233
*
3334
* Portions Copyright (c) 2010-2013, PostgreSQL Global Development Group
@@ -1045,15 +1046,17 @@ WalSndLoop(void)
10451046

10461047
/*
10471048
* When SIGUSR2 arrives, we send any outstanding logs up to the
1048-
* shutdown checkpoint record (i.e., the latest record) and exit.
1049+
* shutdown checkpoint record (i.e., the latest record), wait
1050+
* for them to be replicated to the standby, and exit.
10491051
* This may be a normal termination at shutdown, or a promotion,
10501052
* the walsender is not sure which.
10511053
*/
10521054
if (walsender_ready_to_stop)
10531055
{
10541056
/* ... let's just be real sure we're caught up ... */
10551057
XLogSend(&caughtup);
1056-
if (caughtup && !pq_is_send_pending())
1058+
if (caughtup && sentPtr == MyWalSnd->flush &&
1059+
!pq_is_send_pending())
10571060
{
10581061
/* Inform the standby that XLOG streaming is done */
10591062
EndCommand("COPY 0", DestRemote);
@@ -1728,7 +1731,8 @@ WalSndLastCycleHandler(SIGNAL_ARGS)
17281731
/*
17291732
* If replication has not yet started, die like with SIGTERM. If
17301733
* replication is active, only set a flag and wake up the main loop. It
1731-
* will send any outstanding WAL, and then exit gracefully.
1734+
* will send any outstanding WAL, wait for it to be replicated to
1735+
* the standby, and then exit gracefully.
17321736
*/
17331737
if (!replication_active)
17341738
kill(MyProcPid, SIGTERM);

0 commit comments

Comments
 (0)