Обсуждение: Fixes required for cross version update testing
Over at [1] there was some discussion of moving knowledge of what's required to be fixed from old branch repos to be able to upgrade them into the core code, instead of having it reside in a buildfarm client module. Here's a piece of WIP for that, in the form of a perl module that provides a function that takes an old version number / tag and provides the set of sql statements that need to be run to make the old repo upgradeable. It still needs a good deal of polish, but it's a start. The advantage is that it makes it far less likely that the buildfarm maintainer (i.e. me for now) is a bottleneck in fixing issues that arise from development. This is by far the biggest area where we have seen buildfarm breakage for cross version upgrade testing. cheers andrew [1] https://postgr.es/m/951602.1673535249@sss.pgh.pa.us -- Andrew Dunstan EDB: https://www.enterprisedb.com
Вложения
On Fri, Jan 13, 2023 at 05:20:41PM -0500, Andrew Dunstan wrote: > Over at [1] there was some discussion of moving knowledge of what's > required to be fixed from old branch repos to be able to upgrade them > into the core code, instead of having it reside in a buildfarm client > module. Is this instead of the idea for the buildfarm to use the same SQL script as the TAP test (upgrade_adapt.sql) ? Discussed various places: https://www.postgresql.org/message-id/flat/1575064.1615060903@sss.pgh.pa.us https://github.com/PGBuildFarm/client-code/pull/23 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0df9641d39057f431655b92b8a490b89c508a0b3 | The long-term plan is to make the buildfarm code re-use this new SQL | file, so as committers are able to fix any compatibility issues in the | tests of pg_upgrade with a refresh of the core code, without having to | poke at the buildfarm client. Note that this is only able to handle the | main regression test suite, and that nothing is done yet for contrib | modules yet (these have more issues like their database names). https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=9814ff550046f825b751803191b29a2fbbc79283 -- Justin
Andrew Dunstan <andrew@dunslane.net> writes: > Here's a piece of WIP for that, in the form of a perl module that > provides a function that takes an old version number / tag and provides > the set of sql statements that need to be run to make the old repo > upgradeable. It still needs a good deal of polish, but it's a start. Oh! I've been hacking on exactly the same idea all day ... https://www.postgresql.org/message-id/891521.1673657296%40sss.pgh.pa.us regards, tom lane
On 2023-01-13 Fr 19:49, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> Here's a piece of WIP for that, in the form of a perl module that >> provides a function that takes an old version number / tag and provides >> the set of sql statements that need to be run to make the old repo >> upgradeable. It still needs a good deal of polish, but it's a start. > Oh! I've been hacking on exactly the same idea all day ... > > https://www.postgresql.org/message-id/891521.1673657296%40sss.pgh.pa.us > > Oh, sorry if I have wasted some of your time. I posted my outline idea and then it itched so I scratched. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
On 2023-01-13 Fr 19:33, Justin Pryzby wrote: > On Fri, Jan 13, 2023 at 05:20:41PM -0500, Andrew Dunstan wrote: >> Over at [1] there was some discussion of moving knowledge of what's >> required to be fixed from old branch repos to be able to upgrade them >> into the core code, instead of having it reside in a buildfarm client >> module. > Is this instead of the idea for the buildfarm to use the same SQL script > as the TAP test (upgrade_adapt.sql) ? > > Discussed various places: > > https://www.postgresql.org/message-id/flat/1575064.1615060903@sss.pgh.pa.us > > https://github.com/PGBuildFarm/client-code/pull/23 > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0df9641d39057f431655b92b8a490b89c508a0b3 > | The long-term plan is to make the buildfarm code re-use this new SQL > | file, so as committers are able to fix any compatibility issues in the > | tests of pg_upgrade with a refresh of the core code, without having to > | poke at the buildfarm client. Note that this is only able to handle the > | main regression test suite, and that nothing is done yet for contrib > | modules yet (these have more issues like their database names). > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=9814ff550046f825b751803191b29a2fbbc79283 > I didn't adopt the PR precisely because it didn't do enough, unlike the module I posted, which supports upgrades all the way from 9.2 forward, and for more databases than just regression. I frankly think this is a better approach. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com