Horton

Re: making relfilenodes 56 bits

Thomas Munro <thomas.munro@gmail.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@gmail.com>
To: Simon Riggs <simon.riggs@enterprisedb.com>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>, Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-06-30T02:42:25Z
Lists: pgsql-hackers 
On Thu, Jun 30, 2022 at 12:41 AM Simon Riggs
<simon.riggs@enterprisedb.com> wrote:
> The reason to mention this now is that it would give more space than
> 56bit limit being suggested here.

Isn't 2^56 enough, though?  Remembering that cluster time runs out
when we've generated 2^64 bytes of WAL, if you want to run out of 56
bit relfile numbers before the end of time you'll need to find a way
to allocate them in less than 2^8 bytes of WAL.  That's technically
possible, since SMgr CREATE records are only 42 bytes long, so you
could craft some C code to do nothing but create (and leak)
relfilenodes, but real usage is always accompanied by catalogue
insertions to connect the new relfilenode to a database object,
without which they are utterly useless.  So in real life, it takes
many hundreds or typically thousands of bytes, much more than 256.

Commits

  1. Fix typos in comments, code and documentation

  2. Increase width of RelFileNumbers from 32 bits to 56 bits.

  3. Move RelFileNumber declarations to common/relpath.h.

  4. Include RelFileLocator fields individually in BufferTag.

  5. Convert macros to static inline functions (buf_internals.h)

  6. Remove the restriction that the relmap must be 512 bytes.

  7. Change internal RelFileNode references to RelFileNumber or RelFileLocator.

  8. Reorder subskiplsn in pg_subscription to avoid alignment issues.

  9. Fix DROP {DATABASE,TABLESPACE} on Windows.

  10. Restructure smgr API as per recent proposal. smgr no longer depends on