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

From Andrew Dunstan
Subject Re: pgsql: Trial fix for old cross-version upgrades.
Date
Msg-id 4f3aca16-5b6e-4231-a13f-ef1c730a8a07@dunslane.net
Whole thread Raw
In response to Re: pgsql: Trial fix for old cross-version upgrades.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
On 2025-02-22 Sa 1:34 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.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




pgsql-committers by date:

Previous
From: Jeff Davis
Date:
Subject: pgsql: Documentation fixups for dumping statistics.
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Trial fix for old cross-version upgrades.