Re: buildfarm warnings

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Alexander Korotkov <akorotkov(at)postgresql(dot)org>
Subject: Re: buildfarm warnings
Date: 2022-02-18 19:56:13
Message-ID: CA+TgmoaezDem1BaM_P877EOQDZ4DnH=oK6tRe4Jur7depBh2qg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 17, 2022 at 3:57 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> True. That would be easy enough.

I played around with this a bit, and of course it is easy enough to
add --progress with or without --verbose to a few tests, but when I
reverted 62cb7427d1e491faf8612a82c2e3711a8cd65422 it didn't make any
tests fail. So then I tried sticking --progress --verbose into
@pg_basebackup_defs so all the tests would run with it, and that did
make some tests fail, but the same ones fail with and without the
patch. So it doesn't seem like we would have caught this particular
problem via this testing method no matter what we did in detail.

If we just want to splatter a few --progress switches around for the
heck of it, we could do something like the attached. But I don't know
if this is best: it seems highly arguable what to do in detail (and
also not worth arguing about, so if someone else feels motivated to do
something different than this, or the same as this, fine by me).

--
Robert Haas
EDB: http://www.enterprisedb.com

Attachment Content-Type Size
splatter-some-progress.patch application/octet-stream 1.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-02-18 20:25:33 Re: Time to drop plpython2?
Previous Message David G. Johnston 2022-02-18 19:46:51 Re: Design of pg_stat_subscription_workers vs pgstats