mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-23 08:00:40 +02:00
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 |
||
---|---|---|
.. | ||
expected | ||
sql | ||
.gitignore | ||
Makefile | ||
meson.build | ||
pg_buffercache_pages.c | ||
pg_buffercache--1.0--1.1.sql | ||
pg_buffercache--1.1--1.2.sql | ||
pg_buffercache--1.2--1.3.sql | ||
pg_buffercache--1.2.sql | ||
pg_buffercache--1.3--1.4.sql | ||
pg_buffercache.control |