Bugs in CreateCheckPoint
hi,
To avoid inserting duplicate checkpoints when the system is idle, the code of CreateCheckPoint make two tests to determine that nothing has happened since the start of the last checkpoint.
But because the layout of XLOG record was changed, the condition would never to be true. The attachment is the patch to fix it, thanks.
Zhang Zq
Attachments:
repeatly-checkpoint.patchapplication/octet-stream; name=repeatly-checkpoint.patchDownload
*** a/src/backend/access/transam/xlog.c
--- b/src/backend/access/transam/xlog.c
***************
*** 8007,8014 **** CreateCheckPoint(int flags)
if ((flags & (CHECKPOINT_IS_SHUTDOWN | CHECKPOINT_END_OF_RECOVERY |
CHECKPOINT_FORCE)) == 0)
{
if (curInsert == ControlFile->checkPoint +
! MAXALIGN(SizeOfXLogRecord + sizeof(CheckPoint)) &&
ControlFile->checkPoint == ControlFile->checkPointCopy.redo)
{
WALInsertLockRelease();
--- 8007,8018 ----
if ((flags & (CHECKPOINT_IS_SHUTDOWN | CHECKPOINT_END_OF_RECOVERY |
CHECKPOINT_FORCE)) == 0)
{
+ size_t checkPointSize;
+
+ checkPointSize = sizeof(CheckPoint);
if (curInsert == ControlFile->checkPoint +
! MAXALIGN(SizeOfXLogRecord + checkPointSize +
! (checkPointSize > 255 ? SizeOfXLogRecordDataHeaderLong : SizeOfXLogRecordDataHeaderShort)) &&
ControlFile->checkPoint == ControlFile->checkPointCopy.redo)
{
WALInsertLockRelease();
On 04/15/2015 07:02 PM, Zhang Zq wrote:
hi,
To avoid inserting duplicate checkpoints when the system is idle, the code of CreateCheckPoint make two tests to determine that nothing has happened since the start of the last checkpoint.
But because the layout of XLOG record was changed, the condition would never to be true. The attachment is the patch to fix it, thanks.
Jeff Janes reported this a while ago, and as it happens, I committed a
fix earlier today. (See
/messages/by-id/552E7611.1000907@iki.fi)
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers