8000 Better fix for "unarchived WAL files get deleted on crash recovery" bug. · danielcode/postgres@b5ec56f · GitHub
[go: up one dir, main page]

Skip to content

Commit b5ec56f

Browse files
committed
Better fix for "unarchived WAL files get deleted on crash recovery" bug.
Revert my earlier fix for the bug that unarchived WAL files get deleted on crash recovery, commit c9cc7e0. We create a .done file for files streamed or restored from archive, so the WAL file recycling logic used during normal operation works just as well during archive recovery. Per Fujii Masao's suggestion.
1 parent fea9346 commit b5ec56f

File tree

1 file changed

+1
-29
lines changed
  • src/backend/access/transam

1 file changed

+1
-29
lines changed

src/backend/access/transam/xlog.c

Lines changed: 1 addition & 29 deletions
Original file line numberDiff line numberDiff line change
@@ -418,7 +418,6 @@ typedef struct XLogCtlData
418418
* recovery. Protected by info_lck.
419419
*/
420420
bool SharedRecoveryInProgress;
421-
bool SharedInArchiveRecovery;
422421

423422
/*
424423
* SharedHotStandbyActive indicates if we're still in crash or archive
@@ -623,7 +622,6 @@ static void XLogArchiveCleanup(const char *xlog);
623622
static void readRecoveryCommandFile(void);
624623
static void exitArchiveRecovery(TimeLineID endTLI,
625624
uint32 endLogId, uint32 endLogSeg);
626-
static bool ArchiveRecoveryInProgress(void);
627625
static bool recoveryStopsHere(XLogRecord *record, bool *includeThis);
628626
static void recoveryPausesHere(void);
629627
static void SetLatestXTime(TimestampTz xtime);
@@ -3573,7 +3571,7 @@ RemoveOldXlogFiles(uint32 log, uint32 seg, XLogRecPtr endptr)
35733571
strspn(xlde->d_name, "0123456789ABCDEF") == 24 &&
35743572
strcmp(xlde->d_name + 8, lastoff + 8) <= 0)
35753573
{
3576-
if (ArchiveRecoveryInProgress() || XLogArchiveCheckDone(xlde->d_name))
3574+
if (XLogArchiveCheckDone(xlde->d_name))
35773575
{
35783576
snprintf(path, MAXPGPATH, XLOGDIR "/%s", xlde->d_name);
35793577

@@ -5291,7 +5289,6 @@ XLOGShmemInit(void)
52915289
*/
52925290
XLogCtl->XLogCacheBlck = XLOGbuffers - 1;
52935291
XLogCtl->SharedRecoveryInProgress = true;
5294-
XLogCtl->SharedInArchiveRecovery = false;
52955292
XLogCtl->SharedHotStandbyActive = false;
52965293
XLogCtl->WalWriterSleeping = false;
52975294
XLogCtl->Insert.currpage = (XLogPageHeader) (XLogCtl->pages);
@@ -5683,7 +5680,6 @@ readRecoveryCommandFile(void)
56835680

56845681
/* Enable fetching from archive recovery area */
56855682
InArchiveRecovery = true;
5686-
XLogCtl->SharedInArchiveRecovery = true;
56875683

56885684
/*
56895685
* If user specified recovery_target_timeline, validate it or compute the
@@ -5722,16 +5718,11 @@ exitArchiveRecovery(TimeLineID endTLI, uint32 endLogId, uint32 endLogSeg)
57225718
{
57235719
char recoveryPath[MAXPGPATH];
57245720
char xlogpath[MAXPGPATH];
5725-
/* use volatile pointer to prevent code rearrangement */
5726-
volatile XLogCtlData *xlogctl = XLogCtl;
57275721

57285722
/*
57295723
* We are no longer in archive recovery state.
57305724
*/
57315725
InArchiveRecovery = false;
5732-
SpinLockAcquire(&xlogctl->info_lck);
5733-
xlogctl->SharedInArchiveRecovery = false;
5734-
SpinLockRelease(&xlogctl->info_lck);
57355726

57365727
/*
57375728
* Update min recovery point one last time.
@@ -7323,25 +7314,6 @@ RecoveryInProgress(void)
73237314
}
73247315
}
73257316

7326-
/*
7327-
* Are we currently in archive recovery? In the startup process, you can just
7328-
* check InArchiveRecovery variable instead.
7329-
*/
7330-
static bool
7331-
ArchiveRecoveryInProgress()
7332-
{
7333-
bool result;
7334-
/* use volatile pointer to prevent code rearrangement */
7335-
volatile XLogCtlData *xlogctl = XLogCtl;
7336-
7337-
/* spinlock is essential on machines with weak memory ordering! */
7338-
SpinLockAcquire(&xlogctl->info_lck);
7339-
result = xlogctl->SharedInArchiveRecovery;
7340-
SpinLockRelease(&xlogctl->info_lck);
7341-
7342-
return result;
7343-
}
7344-
73457317
/*
73467318
* Is HotStandby active yet? This is only important in special backends
73477319
* since normal backends won't ever be able to connect until this returns

0 commit comments

Comments
 (0)
0