[PATCH] Refactor SLRU to always use long file names
Aleksander Alekseev <aleksander@timescale.com>
From: Aleksander Alekseev <aleksander@timescale.com>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-09-11T13:07:06Z
Lists: pgsql-hackers
Attachments
- v1-0001-Always-use-long-SLRU-segment-file-names.patch (application/octet-stream) patch v1-0001
Hi, Commit 4ed8f0913bfd introduced long SLRU file names. The proposed patch removes SlruCtl->long_segment_names flag and makes SLRU always use long file names. This simplifies both the code and the API. Corresponding changes to pg_upgrade are included. One drawback I see is that technically SLRU is an exposed API and changing it may affect third-party code. I'm not sure if we should seriously worry about this. Firstly, the change is trivial and secondly, it's not clear whether such third-party code even exists (we broke this API just recently in 4ed8f0913bfd and no one complained). I didn't include any tests for the new pg_upgrade code. To my knowledge we test it manually, with buildfarm members and during alpha- and beta-testing periods. Please let me know if you think there should be a corresponding TAP test. Thoughts? -- 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