Re: pgsql: Trial fix for old cross-version upgrades.
От | Andrew Dunstan |
---|---|
Тема | Re: pgsql: Trial fix for old cross-version upgrades. |
Дата | |
Msg-id | 4f3aca16-5b6e-4231-a13f-ef1c730a8a07@dunslane.net обсуждение исходный текст |
Ответ на | Re: pgsql: Trial fix for old cross-version upgrades. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: