From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [v15 beta] pg_upgrade failed if earlier executed with -c switch |
Date: | 2022-06-10 21:45:11 |
Message-ID: | ad99dc65-7a47-7c83-4875-f5b56c18c918@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2022-06-10 22:40:03 | Re: replacing role-level NOINHERIT with a grant-level option |
Previous Message | Peter Eisentraut | 2022-06-10 20:36:27 | Re: replacing role-level NOINHERIT with a grant-level option |