On 2025-02-21 Fr 10:11 PM, Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
>> In 002_pg_upgrade.pl, I disabled autovacuum and restarted after the
>> regression run. In other words, in the old cluster, autovacuum did have
>> a chance to run, just not after the first dumpall.
> The hack I posted should prevent autovacuum from running either
> before or after dumping, in either cluster.
>
> However, it occurred to me to try forcing a HEAD-to-HEAD upgrade,
> a case the buildfarm animals have not been able to reach.
> And *it failed*!? (Diffs attached.) So that eliminates the
> theory that this is a cross-version compatibility problem, or
> at least that is not our only problem. 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.
>
>
Yeah, I don't know.
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
What I'm thinking of doing is running all the eligible upgrades rather
than stopping on the first failure.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
