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
signature.asc
Description: PGP signature
