Re: pgsql: Trial fix for old cross-version upgrades.

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 2025-02-21 Fr 10:11 PM, Tom Lane wrote:
>> ... It seems there is
>> something different between what TestUpgradeXversion.pm is doing
>> and what 002_pg_upgrade.pl is doing. No clue what, although it
>> does look like an additional round of analyze'ing has added more
>> stats than were there before.

Hah! Looking at the script with less bleary eyes, I see it does
this after pg_upgrade:

if (-e "$installdir/analyze_new_cluster.sh")
{
system( "cd $installdir && sh ./analyze_new_cluster.sh "
. qq{> "$upgrade_loc/$oversion-analyse.log" 2>&1 });
return if $?;
}
else
{
system( qq{"$installdir/bin/vacuumdb" --all --analyze-only }
. qq{> "$upgrade_loc/$oversion-analyse.log" 2>&1 });
return if $?;
}

So there's our extra round of ANALYZE right there. I diked out the
vacuumdb call and things are working much better. It seems to pass
for branches back through 9.3, and upgrade from 9.2 has only some
diffs for relallvisible (see attached). We still need to figure out
why that is, but a quick-n-dirty patch could just be to make the dump
comparison logic ignore relallvisible diffs.

We might want to make this vacuumdb invocation dependent on version,
but I could also see just removing it entirely.

> Here's what I have so far:

> . for HEAD/18 disable running the analyze script / vacuumdb --analyze.
> . turn off autovacuum on the old and upgraded database.
> . reverse the order of testing so we do newest first

Check.

> What I'm thinking of doing is running all the eligible upgrades rather
> than stopping on the first failure.

Seems like possibly wasted work --- I'd be content with
newest-to-oldest.

regards, tom lane