Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 14 Nov 2024 10:11:41 +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: <ZzVOTc3ZgPWfEQut@paquier.xyz>
References: <CAJ7c6TOy7fUW9MuNeOWor3cSFnQg9tgz=mjXHDb94GORtM_Eyg@mail.gmail.com>
 <ZuIt9-loAPa8tvcY@paquier.xyz>
 <CAJ7c6TNs8RY4Yvng4m375mAvsS4wHeUcqR8t4b2_i2j=PE6iNQ@mail.gmail.com>
 <Zy2RtPwzjdtgjLnE@paquier.xyz>
 <CAJ7c6TMq46VGLtMVCev2z0QUfUYO1Fnfug0ouLuEZby2sa0+FQ@mail.gmail.com>
 <CAJ7c6TPrdgo8YD0-YPbdiRXQDHUCJ66OdhKgn+SJeQcmrB3s_g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="zkscBWd7EnQj/C0P"
Content-Disposition: inline
In-Reply-To: <CAJ7c6TPrdgo8YD0-YPbdiRXQDHUCJ66OdhKgn+SJeQcmrB3s_g@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/ZzVOTc3ZgPWfEQut%40paquier.xyz>
Precedence: bulk


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

On Tue, Nov 12, 2024 at 05:37:02PM +0300, Aleksander Alekseev wrote:
> Also it occured to me that as a 4th option we could just get rid of
> this check. Users however will pay the price every time they execute
> pg_upgrade so I doubt we are going to do this.

We cannot remove the check, or Nathan will come after us as he's
working hard on reducing the time pg_upgrade takes.  We should not
make it longer if there is no need to.

The scans may be quite long as well, actually, which could be a
bottleneck.  Did you measure the runtime with a maximized (still
realistic) pool of files for these SLRUs in the upgrade time?  For
upgrades, data would be the neck.

# equals SLRU_SEG_FILENAMES_CHANGE_CAT_VER in pg_upgrade.h
my $slru_seg_filenames_change_cat_ver = 202411121;
[...]
open my $fh, "+<", $pg_control_fname or die $!;
binmode($fh);
sysseek($fh, 12, 0);
my $binval = pack("L!", $slru_seg_filenames_change_cat_ver - 1);
syswrite($fh, $binval, 4);
close($fh);

Control file manipulation may be useful as a routine in Cluster.pm,
based on an offset in the file and a format to pack as argument?  Note
that this also depends on the system endianness, see 039_end_of_wal.pl.
It's one of these things I could see myself reuse to force a state in
the cluster and make a test cheaper, for example.  You don't really
need the lookup part, actually?  You would just need the part where
the control file is rewritten, which should be OK as long as the
cluster is freshly initdb'd meaning that there should be nothing that
interacts with the new value set.  pg_upgrade only has CAT_VER flags
for some multixact changes and the jsonb check from 9.4.
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmc1Tk0ACgkQnvQgOdby
QH1QLw//QdwGtrgD3yDDoNPFW5wW7xVmDOgJUSg2FLSQVuFH783aA+Q5JljSZydd
gcGdjXpo+DdbGApjnQ+6ShzO5LvvWk5mRhxf3VPntjPfxdx0yp5mmsG0x5gary6s
Vk55XofppI/rgLA36HIu6nGw3hfH7ZIto5n2MbAxG8ZDJGCNEujpKI2nVT0TK85E
TDhCrAsQp2ppPfRIyQkoLBl3av8/uzGj/TtuSJiYRbx/9g0C1Oji9MYo3wM4AFAm
od8Q/ZVZ3x2MEiDeVSrcv0D8Baa+pFx6XGEUJva2PbLMP/6K1n1zVGo2EUTt0X/I
B7++GyBcP7yXoL9J8Nggih8kCYx3j401CbsMxeaLAgikP7fsjY/nfO8mb3HkZ5Ho
xleW/c93yaJQxowN+8/0Z0ZuS6vzWJyhMQmyp01I/n5lggpWfQ0oQl0dtWQENvQa
TKm0IzmwfW2o8/8sHjSK09+BcjZtuWz50NwoxOnaSDmb4EqeNoUrU5pDcw/JyqGu
5ERJgukwGLGMqZ1pGokQ+CksvM1+/hReAeUJiCDnqB8J35m2Eo4pe2v/lLJaH/t+
uB1a//KlF6NSN2w7H2CRrZPYhTeKtVrqN+9/QdA7Gv5irFg60Fgd2dSB5k1EmlKZ
mdJOMYoNN5ytDKjoHjJS5/95ovXAf/fu6TZfaehnKlACarkWkUU=
=LTBb
-----END PGP SIGNATURE-----

--zkscBWd7EnQj/C0P--