appendStringInfo(buf, "%s", xlrec->rp_name);
}
- else if (info == XLOG_FPI)
+ else if (info == XLOG_FPI || info == XLOG_FPI_FOR_HINT)
{
/* no further information to print */
}
case XLOG_FPI:
id = "FPI";
break;
+ case XLOG_FPI_FOR_HINT:
+ id = "FPI_FOR_HINT";
+ break;
}
return id;
XLogRecPtr lsn = record->EndRecPtr;
/* in XLOG rmgr, backup blocks are only used by XLOG_FPI records */
- Assert(!XLogRecHasAnyBlockRefs(record) || info == XLOG_FPI);
+ Assert(info == XLOG_FPI || info == XLOG_FPI_FOR_HINT ||
+ !XLogRecHasAnyBlockRefs(record));
if (info == XLOG_NEXTOID)
{
{
/* nothing to do here */
}
- else if (info == XLOG_FPI)
+ else if (info == XLOG_FPI || info == XLOG_FPI_FOR_HINT)
{
Buffer buffer;
* block. The block reference must include a full-page image -
* otherwise there would be no point in this record.
*
- * Since the only change in these backup block are hint bits, there
- * are no recovery conflicts generated.
+ * No recovery conflicts are generated by these generic records - if a
+ * resource manager needs to generate conflicts, it has to define a
+ * separate WAL record type and redo routine.
*
- * This also means there is no corresponding API call for this, so an
- * smgr implementation has no need to implement anything. Which means
- * nothing is needed in md.c etc
+ * XLOG_FPI_FOR_HINT records are generated when a page needs to be
+ * WAL- logged because of a hint bit update. They are only generated
+ * when checksums are enabled. There is no difference in handling
+ * XLOG_FPI and XLOG_FPI_FOR_HINT records, they use a different info
+ * code just to distinguish them for statistics purposes.
*/
if (XLogReadBufferForRedo(record, 0, &buffer) != BLK_RESTORED)
elog(ERROR, "unexpected XLogReadBufferForRedo result when restoring backup block");
BufferGetTag(buffer, &rnode, &forkno, &blkno);
XLogRegisterBlock(0, &rnode, forkno, blkno, copied_buffer, flags);
- recptr = XLogInsert(RM_XLOG_ID, XLOG_FPI);
+ recptr = XLogInsert(RM_XLOG_ID, XLOG_FPI_FOR_HINT);
}
return recptr;