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.

1 files changed, 3 insertions, 3 deletions

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;