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

Commit619dea4

Browse files
committed
Rework order of end-of-recovery actions to delay timeline history write
A critical failure in some of the end-of-recovery actions before theend-of-recovery record is written can cause PostgreSQL to reactinconsistently with the rest of the cluster in the event of a crashbefore the final record is written. Two such failures are for examplean error while processing a two-phase state files or when operating onrecovery.conf. With this commit, the failures are still consideredFATAL, but the write of the timeline history file is delayed as much aspossible so as the window between the moment the file is written and theend-of-recovery record is generated gets minimized. This way, in theevent of a crash or a failure, the new timeline decided at promotionwill not seem taken by other nodes in the cluster. It is not reallypossible to reduce to zero this window, hence one could still seefailures if a crash happens between the history file write and theend-of-recovery record, so any future code should be careful whenadding new end-of-recovery actions. The original report from MagnusHagander mentioned a renamed recovery.conf as original end-of-recoveryfailure which caused a timeline to be seen as taken but the subsequentprocessing on the now-missing recovery.conf cause the startup process toissue stop on FATAL, which at follow-up startup made the systeminconsistent because of on-disk changes which already happened.Processing of two-phase state files still needs some work as corruptedentries are simply ignored now. This is left as a future item and thiscommit fixes the original complain.Reported-by: Magnus HaganderAuthor: Heikki LinnakangasReviewed-by: Alexander Korotkov, Michael Paquier, David SteeleDiscussion:https://postgr.es/m/CABUevEz09XY2EevA2dLjPCY-C5UO4Hq=XxmXLmF6ipNFecbShQ@mail.gmail.com
1 parent741ad15 commit619dea4

File tree

1 file changed

+25
-12
lines changed
  • src/backend/access/transam

1 file changed

+25
-12
lines changed

‎src/backend/access/transam/xlog.c‎

Lines changed: 25 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -7171,6 +7171,13 @@ StartupXLOG(void)
71717171
}
71727172
}
71737173

7174+
/*
7175+
* Pre-scan prepared transactions to find out the range of XIDs present.
7176+
* This information is not quite needed yet, but it is positioned here so
7177+
* as potential problems are detected before any on-disk change is done.
7178+
*/
7179+
oldestActiveXID=PrescanPreparedTransactions(NULL,NULL);
7180+
71747181
/*
71757182
* Consider whether we need to assign a new timeline ID.
71767183
*
@@ -7219,6 +7226,24 @@ StartupXLOG(void)
72197226
else
72207227
snprintf(reason,sizeof(reason),"no recovery target specified");
72217228

7229+
/*
7230+
* We are now done reading the old WAL. Turn off archive fetching if
7231+
* it was active, and make a writable copy of the last WAL segment.
7232+
* (Note that we also have a copy of the last block of the old WAL in
7233+
* readBuf; we will use that below.)
7234+
*/
7235+
exitArchiveRecovery(EndOfLogTLI,EndOfLog);
7236+
7237+
/*
7238+
* Write the timeline history file, and have it archived. After this
7239+
* point (or rather, as soon as the file is archived), the timeline
7240+
* will appear as "taken" in the WAL archive and to any standby
7241+
* servers. If we crash before actually switching to the new
7242+
* timeline, standby servers will nevertheless think that we switched
7243+
* to the new timeline, and will try to connect to the new timeline.
7244+
* To minimize the window for that, try to do as little as possible
7245+
* between here and writing the end-of-recovery record.
7246+
*/
72227247
writeTimeLineHistory(ThisTimeLineID,recoveryTargetTLI,
72237248
EndRecPtr,reason);
72247249
}
@@ -7227,15 +7252,6 @@ StartupXLOG(void)
72277252
XLogCtl->ThisTimeLineID=ThisTimeLineID;
72287253
XLogCtl->PrevTimeLineID=PrevTimeLineID;
72297254

7230-
/*
7231-
* We are now done reading the old WAL. Turn off archive fetching if it
7232-
* was active, and make a writable copy of the last WAL segment. (Note
7233-
* that we also have a copy of the last block of the old WAL in readBuf;
7234-
* we will use that below.)
7235-
*/
7236-
if (ArchiveRecoveryRequested)
7237-
exitArchiveRecovery(EndOfLogTLI,EndOfLog);
7238-
72397255
/*
72407256
* Prepare to write WAL starting at EndOfLog position, and init xlog
72417257
* buffer cache using the block containing the last record from the
@@ -7288,9 +7304,6 @@ StartupXLOG(void)
72887304
XLogCtl->LogwrtRqst.Write=EndOfLog;
72897305
XLogCtl->LogwrtRqst.Flush=EndOfLog;
72907306

7291-
/* Pre-scan prepared transactions to find out the range of XIDs present */
7292-
oldestActiveXID=PrescanPreparedTransactions(NULL,NULL);
7293-
72947307
/*
72957308
* Update full_page_writes in shared memory and write an XLOG_FPW_CHANGE
72967309
* record before resource manager writes cleanup WAL records or checkpoint

0 commit comments

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