[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

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 →
  1. Widen MultiXactOffset to 64 bits

  2. Index SLRUs by 64-bit integers rather than by 32-bit integers