From b8b69d89905e04b910bcd65efce1791477b45d35 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 13 Jun 2012 18:17:09 -0400 Subject: [PATCH] Revert "Reduce checkpoints and WAL traffic on low activity database server" This reverts commit 18fb9d8d21a28caddb72c7ffbdd7b96d52ff9724. Per discussion, it does not seem like a good idea to allow committed changes to go un-checkpointed indefinitely, as could happen in a low-traffic server; that makes us entirely reliant on the WAL stream with no redundancy that might aid data recovery in case of disk failure. This re-introduces the original problem of hot-standby setups generating a small continuing stream of WAL traffic even when idle, but there are other ways to address that without compromising crash recovery, so we'll revisit that issue in a future release cycle. --- src/backend/access/transam/xlog.c | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index bcb71c45b2..0d68760e81 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -7646,10 +7646,6 @@ CreateCheckPoint(int flags) uint32 freespace; uint32 _logId; uint32 _logSeg; - uint32 redo_logId; - uint32 redo_logSeg; - uint32 insert_logId; - uint32 insert_logSeg; TransactionId *inCommitXids; int nInCommit; @@ -7726,8 +7722,8 @@ CreateCheckPoint(int flags) LWLockAcquire(WALInsertLock, LW_EXCLUSIVE); /* - * If this isn't a shutdown or forced checkpoint, and we have not switched - * to the next WAL file since the start of the last checkpoint, skip the + * If this isn't a shutdown or forced checkpoint, and we have not inserted + * any XLOG records since the start of the last checkpoint, skip the * checkpoint. The idea here is to avoid inserting duplicate checkpoints * when the system is idle. That wastes log space, and more importantly it * exposes us to possible loss of both current and previous checkpoint @@ -7735,11 +7731,10 @@ CreateCheckPoint(int flags) * (Perhaps it'd make even more sense to checkpoint only when the previous * checkpoint record is in a different xlog page?) * - * While holding the WALInsertLock we find the current WAL insertion point - * and compare that with the starting point of the last checkpoint, which - * is the redo pointer. We use the redo pointer because the start and end - * points of a checkpoint can be hundreds of files apart on large systems - * when checkpoint writes are spread out over time. + * We have to make two tests to determine that nothing has happened since + * the start of the last checkpoint: current insertion point must match + * the end of the last checkpoint record, and its redo pointer must point + * to itself. */ if ((flags & (CHECKPOINT_IS_SHUTDOWN | CHECKPOINT_END_OF_RECOVERY | CHECKPOINT_FORCE)) == 0) @@ -7747,10 +7742,13 @@ CreateCheckPoint(int flags) XLogRecPtr curInsert; INSERT_RECPTR(curInsert, Insert, Insert->curridx); - XLByteToSeg(curInsert, insert_logId, insert_logSeg); - XLByteToSeg(ControlFile->checkPointCopy.redo, redo_logId, redo_logSeg); - if (insert_logId == redo_logId && - insert_logSeg == redo_logSeg) + if (curInsert.xlogid == ControlFile->checkPoint.xlogid && + curInsert.xrecoff == ControlFile->checkPoint.xrecoff + + MAXALIGN(SizeOfXLogRecord + sizeof(CheckPoint)) && + ControlFile->checkPoint.xlogid == + ControlFile->checkPointCopy.redo.xlogid && + ControlFile->checkPoint.xrecoff == + ControlFile->checkPointCopy.redo.xrecoff) { LWLockRelease(WALInsertLock); LWLockRelease(CheckpointLock); -- 2.40.0