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



Reply via email to