Re: [PATCH] Refactor SLRU to always use long file names
Aleksander Alekseev <aleksander@tigerdata.com>
From: Aleksander Alekseev <aleksander@tigerdata.com>
To: pgsql-hackers@lists.postgresql.org
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
Rustam ALLAKOV <rustamallakov@gmail.com>, Michael Paquier <michael@paquier.xyz>
Date: 2026-04-08T10:09:38Z
Lists: pgsql-hackers
Attachments
- v9-0001-Always-use-long-SLRU-segment-file-names.patch (text/x-patch) patch v9-0001
Hi, > > Since commit bd8d9c9bdf "Widen MultiXactOffset to 64 bits", > > "pg_multixact/members" should not be in that list anymore. > > I missed this one. Fixed, thanks. > > > Also, it seems misleading that a function called "check_*" doesn't > > merely check for things, but renames files. > > Fair point. I renamed it to `ensure_long_slru_segment_filenames`. > > > Could we copy/link them with the new long names to begin with? > > That's an interesting idea. > > What I personally don't like about it is the fact that a single > migration will affect the logic of every run of pg_upgrade, even in > the far future, for instances that don't need this migration. > Previously I showed [1] that the entire migration takes little time > (note that we had to migrate pg_multixact/members back then). So I > don't think this optimization is a good idea in the long run, unless > we reach a consensus on the opposite. Rebased. -- Best regards, Aleksander Alekseev
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Widen MultiXactOffset to 64 bits
- bd8d9c9bdfa0 19 (unreleased) cited
-
Index SLRUs by 64-bit integers rather than by 32-bit integers
- 4ed8f0913bfd 17.0 cited