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 cbb61bb899d63bfa6d2f3fdb88f2ca41f95e255b..0932e600a77e881ada852fa6670be7adba3615ea 100644 (file)
--- a/src/backend/access/transam/xlogutils.c
+++ b/src/backend/access/transam/xlogutils.c
@@ -371,6 +371,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;
@@ -380,6 +382,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 5eff617ed7adf7fc41cd55bfe792862ae0d93719..d7f782942077a743a391222dc1e2acc7e9ef0332 100644 (file)
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -269,6 +269,8 @@ ReadBufferWithoutRelcache(RelFileNode rnode, ForkNumber forkNum,
 
        SMgrRelation smgr = smgropen(rnode, InvalidBackendId);
 
+       Assert(InRecovery);
+
        return ReadBuffer_common(smgr, RELPERSISTENCE_PERMANENT, forkNum, blockNum,
                                                         mode, strategy, &hit);
 }