1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-03 20:02:46 +03:00

Increase width of RelFileNumbers from 32 bits to 56 bits.

RelFileNumbers are now assigned using a separate counter, instead of
being assigned from the OID counter. This counter never wraps around:
if all 2^56 possible RelFileNumbers are used, an internal error
occurs. As the cluster is limited to 2^64 total bytes of WAL, this
limitation should not cause a problem in practice.

If the counter were 64 bits wide rather than 56 bits wide, we would
need to increase the width of the BufferTag, which might adversely
impact buffer lookup performance. Also, this lets us use bigint for
pg_class.relfilenode and other places where these values are exposed
at the SQL level without worrying about overflow.

This should remove the need to keep "tombstone" files around until
the next checkpoint when relations are removed. We do that to keep
RelFileNumbers from being recycled, but now that won't happen
anyway. However, this patch doesn't actually change anything in
this area; it just makes it possible for a future patch to do so.

Dilip Kumar, based on an idea from Andres Freund, who also reviewed
some earlier versions of the patch. Further review and some
wordsmithing by me. Also reviewed at various points by Ashutosh
Sharma, Vignesh C, Amul Sul, Álvaro Herrera, and Tom Lane.

Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
This commit is contained in:
Robert Haas
2022-09-27 13:25:21 -04:00
parent 2f47715cc8
commit 05d4cbf9b6
70 changed files with 693 additions and 289 deletions

View File

@ -14375,10 +14375,14 @@ ATExecSetTableSpace(Oid tableOid, Oid newTableSpace, LOCKMODE lockmode)
}
/*
* Relfilenumbers are not unique in databases across tablespaces, so we
* need to allocate a new one in the new tablespace.
* 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, NULL,
newrelfilenumber = GetNewRelFileNumber(newTableSpace,
rel->rd_rel->relpersistence);
/* Open old and new relation */