Properly set relpersistence for fake relcache entries.

This can result in buffers failing to be properly flushed at
checkpoint time, leading to data loss.

Report, diagnosis, and patch by Jeff Davis.

diff --git a/src/backend/access/transam/xlogutils.c b/src/backend/access/transam/xlogutils.c
index 6ddcc59b37a45941fd17f8e0b7d3ff0976b346e0..5676120a86310fb167de380810cc738a60397f43 100644 (file)
--- a/src/backend/access/transam/xlogutils.c
+++ b/src/backend/access/transam/xlogutils.c
@@ -394,6 +394,8 @@ CreateFakeRelcacheEntry(RelFileNode rnode)
    FakeRelCacheEntry fakeentry;
    Relation    rel;
 
+   Assert(InRecovery);
+
    /* Allocate the Relation struct and all related space in one block. */
    fakeentry = palloc0(sizeof(FakeRelCacheEntryData));
    rel = (Relation) fakeentry;
@@ -403,6 +405,9 @@ CreateFakeRelcacheEntry(RelFileNode rnode)
    /* We will never be working with temp rels during recovery */
    rel->rd_backend = InvalidBackendId;
 
+   /* It must be a permanent table if we're in recovery. */
+   rel->rd_rel->relpersistence = RELPERSISTENCE_PERMANENT;
+
    /* We don't know the name of the relation; use relfilenode instead */
    sprintf(RelationGetRelationName(rel), "%u", rnode.relNode);
 

diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index a3bf9a4d44e9d880e42ccf53e0fcc02d2e7a04fa..f1c29e9d4a89b31e1994d8d52e6e6c53daf11226 100644 (file)
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -271,6 +271,8 @@ ReadBufferWithoutRelcache(RelFileNode rnode, ForkNumber forkNum,
 
    SMgrRelation smgr = smgropen(rnode, InvalidBackendId);
 
+   Assert(InRecovery);
+
    return ReadBuffer_common(smgr, RELPERSISTENCE_PERMANENT, forkNum, blockNum,
                             mode, strategy, &hit);
 }