Commit b8b69d89 authored by Tom Lane's avatar Tom Lane

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

This reverts commit 18fb9d8d.  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.
parent 8b23db94
......@@ -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);
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment