From a448e49bcbe40fb72e1ed85af910dd216d45bad8 Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Wed, 28 Sep 2022 09:45:27 -0400 Subject: Revert 56-bit relfilenode change and follow-up commits. There are still some alignment-related failures in the buildfarm, which might or might not be able to be fixed quickly, but I've also just realized that it increased the size of many WAL records by 4 bytes because a block reference contains a RelFileLocator. The effect of that hasn't been studied or discussed, so revert for now. --- src/backend/access/transam/xlogutils.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'src/backend/access/transam/xlogutils.c') diff --git a/src/backend/access/transam/xlogutils.c b/src/backend/access/transam/xlogutils.c index ffda2c210b7..563cba258dd 100644 --- a/src/backend/access/transam/xlogutils.c +++ b/src/backend/access/transam/xlogutils.c @@ -619,17 +619,17 @@ CreateFakeRelcacheEntry(RelFileLocator rlocator) rel->rd_rel->relpersistence = RELPERSISTENCE_PERMANENT; /* We don't know the name of the relation; use relfilenumber instead */ - sprintf(RelationGetRelationName(rel), UINT64_FORMAT, rlocator.relNumber); + sprintf(RelationGetRelationName(rel), "%u", rlocator.relNumber); /* * We set up the lockRelId in case anything tries to lock the dummy - * relation. Note that this is fairly bogus since relNumber are completely + * relation. Note that this is fairly bogus since relNumber may be * different from the relation's OID. It shouldn't really matter though. * In recovery, we are running by ourselves and can't have any lock * conflicts. While syncing, we already hold AccessExclusiveLock. */ rel->rd_lockInfo.lockRelId.dbId = rlocator.dbOid; - rel->rd_lockInfo.lockRelId.relId = (Oid) rlocator.relNumber; + rel->rd_lockInfo.lockRelId.relId = rlocator.relNumber; rel->rd_smgr = NULL; -- cgit v1.2.3