Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 12 Sep 2024 08:55:35 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Aleksander Alekseev <aleksander@timescale.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: [PATCH] Refactor SLRU to always use long file names
Message-ID: <ZuIt9-loAPa8tvcY@paquier.xyz>
References: <CAJ7c6TOy7fUW9MuNeOWor3cSFnQg9tgz=mjXHDb94GORtM_Eyg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="ygILfdm7rcBtz08s"
Content-Disposition: inline
In-Reply-To: <CAJ7c6TOy7fUW9MuNeOWor3cSFnQg9tgz=mjXHDb94GORtM_Eyg@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/ZuIt9-loAPa8tvcY%40paquier.xyz>
Precedence: bulk


--ygILfdm7rcBtz08s
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Sep 11, 2024 at 04:07:06PM +0300, Aleksander Alekseev wrote:
> 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.

That's leaner, indeed.

> 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).

Any third-party code using custom SLRUs would need to take care of
handling their upgrade path outside pg_upgrade.  Not sure there are
any of them, TBH, but let's see.

> 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.

Removing the old API means that it is impossible to test a move from
short to long file names.  That's OK by me to rely on the pg_upgrade
paths in the buildfarm code.  We have a few of them.

There is one thing I am wondering, here, though, which is to think
harder about a validity check at the end of 002_pg_upgrade.pl to make
sure that all the SLRU use long file names after running the tests.
That would mean thinking about a mechanism to list all of them from a
backend, rather than hardcode a list of them.  Perhaps that's not
worth it, just dropping an idea in the bucket of ideas.  I would guess
in the shape of a catalog that's able to represent at SQL level all
the SLRUs that exist in a backend.
--
Michael

--ygILfdm7rcBtz08s
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmbiLfcACgkQnvQgOdby
QH1Fdg/9H8Osq4XYbTR2HKCOP3GXLz4HO1bHxgKZri9gO1WLHTSwQ4iJX+BZq4T/
2Tl8r+e3p4IwAAH6xYWR4myxFeh2w2WOZXhXpLemw891Nm7Rsr7wa/Gf+krra0tA
eFbp4Da478Xt9dh/Byms4HugxLeBli6g/KGYrx2LNY5SHbkfb1RYuxHXxKJuSd/m
ILFOGWUmmKavmUCa2ffNCI4CmmxlW4oMCmZEvA63o0ESOftRB8q+SqpMTZt0usqY
WziZzq/xnFFlWz3ndG/7nhl6FxmIeM85HkzY09wb1ve0DWgmbiGX89GmHet0h2TM
2rFq08s7eH8uy+bYOJ+T8XcSgbbx2myvxNVykOQ4a5eSxsmRNjA0ZPgSUsiap1nu
pG1smX4sdoqUJ1v+/3/wAvyWZqC/vuzwbHXILokWQjBOIyHGJayP3EvVM2H09U06
yBR9htIatSl+ZRQa+SLU4C0Z3Lwk2OBJHRBYQV2ptRjTgW/Oh9sanY92dQb1z9Y7
cuJbMLTuR08h+azht/JjGiX2MU0c1YJdmrBPaUNmUeuhqQaENFJ0AquM1f8HsqZ+
kQhavbHjw6JBXZaFVfk5yNKRS24g+ryIwH5A5wP4QAFcp+j3BV9RI2eDMAANqvE+
jQVreYDkmKYtBONqeBt3KhpQIFjieZ+E4W/1efB+LNcOcFaalZw=
=I7yS
-----END PGP SIGNATURE-----

--ygILfdm7rcBtz08s--