Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Michael Paquier <michael@paquier.xyz>,
Justin Pryzby <pryzby@telsasoft.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, Tom Lane <tgl@sss.pgh.pa.us>,
tushar <tushar.ahuja@enterprisedb.com>, pgsql-hackers@postgresql.org
Date: 2022-06-10T21:45:11Z
Lists: pgsql-hackers
On 2022-06-08 We 20:53, Michael Paquier wrote: > On Wed, Jun 08, 2022 at 04:13:37PM -0500, Justin Pryzby wrote: >> On Wed, Jun 08, 2022 at 10:55:29AM +0900, Michael Paquier wrote: >>> And applied, to take care of this open item. >> Shouldn't this wait for the buildfarm to be updated again ? > The TAP logic is able to find any logs by itself on failure, so what > would be impacted is the case of the tests running pg_upgrade via the > past route in TestUpgrade.pm (it had better not run in the buildfarm > client for 15~ and I am wondering if it would be worth backpatching > the TAP test once it brews a bit more). Anyway, seeing my time sheet > for the next couple of days coupled with a potential beta2 in the very > short term and with the broken upgrade workflow, I have given priority > to fix the issue because that's what impacts directly people looking > at 15 and testing their upgrades, which is what Tushar did. > > Saying that, I have already sent a pull request to the buildfarm repo > to refresh the set of logs, as of the patch attached. This updates > the logic so as this would work for any changes in the structure of > pg_upgrade_output.d/, fetching any files prefixed by ".log". The module is already a noop if there's a TAP test for pg_upgrade. So I don't understand the point of the PR at all. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Restructure pg_upgrade output directories for better idempotence
- 4fff78f00910 15.0 landed