Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
Heikki Linnakangas <hlinnaka@iki.fi>
On 09/03/2023 17:21, Aleksander Alekseev wrote:
> v57-0001-Index-SLRUs-by-64-bit-integers-rather-than-by-32.patch
Reviewing this now. I think it's almost ready to be committed.
There's another big effort going on to move SLRUs to the regular buffer
cache (https://commitfest.postgresql.org/43/3514/). I wonder how moving
to 64 bit page numbers will affect that. BlockNumber is still 32 bits,
after all.
> +/*
> + * An internal function used by SlruScanDirectory().
> + *
> + * Returns true if a file with a name of a given length may be a correct
> + * SLRU segment.
> + */
> +static inline bool
> +SlruCorrectSegmentFilenameLength(SlruCtl ctl, size_t len)
> +{
> + if (ctl->long_segment_names)
> + return (len == 12);
> + else
> +
> + /*
> + * XXX Should we still consider 5 and 6 to be a correct length? It
> + * looks like it was previously allowed but now SlruFileName() can't
> + * return such a name.
> + */
> + return (len == 4 || len == 5 || len == 6);
> +}
Huh, I didn't realize that 5 and 6 character SLRU segment names are
possible. But indeed they are. Commit 638cf09e76d allowed 5-character
lengths:
> commit 638cf09e76d70dd83d8123e7079be6c0532102d2
> Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
> Date: Thu Jan 2 18:17:29 2014 -0300
>
> Handle 5-char filenames in SlruScanDirectory
>
> Original users of slru.c were all producing 4-digit filenames, so that
> was all that that code was prepared to handle. Changes to multixact.c
> in the course of commit 0ac5ad5134f made pg_multixact/members create
> 5-digit filenames once a certain threshold was reached, which
> SlruScanDirectory wasn't prepared to deal with; in particular,
> 5-digit-name files were not removed during truncation. Change that
> routine to make it aware of those files, and have it process them just
> like any others.
>
> Right now, some pg_multixact/members directories will contain a mixture
> of 4-char and 5-char filenames. A future commit is expected fix things
> so that each slru.c user declares the correct maximum width for the
> files it produces, to avoid such unsightly mixtures.
>
> Noticed while investigating bug #8673 reported by Serge Negodyuck.
>
And later commit 73c986adde5, which introduced commit_ts, allowed 6
characters. With 8192 block size, pg_commit_ts segments are indeed 5
chars wide, and with 512 block size, 6 chars are needed.
This patch makes the filenames always 12 characters wide (for SLRUs that
opt-in to the new naming). That's actually not enough for the full range
that a 64 bit page number can represent. Should we make it 16 characters
now, to avoid repeating the same mistake we made earlier? Or make it
more configurable, on a per-SLRU basis. One reason I don't want to just
make it 16 characters is that WAL segment filenames are also 16 hex
characters, which could cause confusion.
--
Heikki Linnakangas
Neon (https://neon.tech)
Commits
-
Fix more holes with SLRU code in need of int64 for segment numbers
- b7935bc10b78 17.0 landed
- bd06cc338d82 18.0 landed
- e367a413b09f 17.0 landed
- c9e24573905b 18.0 landed
-
Use more consistently int64 for page numbers in SLRU-related code
- 165ea79a6077 17.0 landed
- 3937cadfd438 18.0 landed
-
Improve comments in slru.{c,h} about segment name format
- 3b279d89cb5c 17.0 landed
- ffb060392961 18.0 landed
-
Reorder actions in ProcArrayApplyRecoveryInfo()
- c64086b79dba 17.0 landed
-
Fix typo in 5a1dfde8334b
- ae2ccf66a261 17.0 landed
-
Fix warning due non-standard inline declaration in 4ed8f0913bfdb5f355
- b589f211e025 17.0 landed
-
Add SLRU tests for 64-bit page case
- a60b8a58f435 17.0 landed
-
Make use FullTransactionId in 2PC filenames
- 5a1dfde8334b 17.0 landed
-
Use larger segment file names for pg_notify
- 2cdf131c46e6 17.0 landed
-
Index SLRUs by 64-bit integers rather than by 32-bit integers
- 4ed8f0913bfd 17.0 landed
-
Keep track of transaction commit timestamps
- 73c986adde5d 9.5.0 cited
-
Handle 5-char filenames in SlruScanDirectory
- 638cf09e76d7 9.4.0 cited