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

On 2025-02-22 Sa 1:34 PM, Tom Lane wrote:
> 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.
>
>

OK, went with that. crake is getting a failure at 9.6 like you saw with
9.2, but things are a whole lot better than they were.

I have updated drongo and fairywren with the new code too, so they
should also improve before long.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com