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/commands/tablecmds.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) (limited to 'src/backend/commands/tablecmds.c') diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c index 1b8e6d57294..7d8a75d23c2 100644 --- a/src/backend/commands/tablecmds.c +++ b/src/backend/commands/tablecmds.c @@ -14375,14 +14375,10 @@ ATExecSetTableSpace(Oid tableOid, Oid newTableSpace, LOCKMODE lockmode) } /* - * Generate a new relfilenumber. We cannot reuse the old relfilenumber - * because of the possibility that that relation will be moved back to the - * original tablespace before the next checkpoint. At that point, the - * first segment of the main fork won't have been unlinked yet, and an - * attempt to create new relation storage with that same relfilenumber - * will fail. - */ - newrelfilenumber = GetNewRelFileNumber(newTableSpace, + * Relfilenumbers are not unique in databases across tablespaces, so we + * need to allocate a new one in the new tablespace. + */ + newrelfilenumber = GetNewRelFileNumber(newTableSpace, NULL, rel->rd_rel->relpersistence); /* Open old and new relation */ -- cgit v1.2.3