Revert "Reduce checkpoints and WAL traffic on low activity database server"

tglsfdc · tglsfdc · commit b8b69d89905e · 2012-06-13T18:48:44.000-04:00
This reverts commit 18fb9d8. 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.
diff --git 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,31 +7722,33 @@ 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
 	 * records if the machine crashes just as we're writing the update.
 	 * (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)
 	{
 		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);
