Re: Move regression.diffs of pg_upgrade test suite

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: Move regression.diffs of pg_upgrade test suite
Дата
Msg-id 20181230162856.GA187973@gust.leadboat.com
обсуждение исходный текст
Ответ на Re: Move regression.diffs of pg_upgrade test suite  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Ответы Re: Move regression.diffs of pg_upgrade test suite  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On Sun, Dec 30, 2018 at 10:41:46AM -0500, Andrew Dunstan wrote:
> On 12/26/18 5:44 PM, Noah Misch wrote:
> > On Wed, Dec 26, 2018 at 05:02:37PM -0500, Tom Lane wrote:
> >> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> >>> On 12/23/18 10:44 PM, Noah Misch wrote:
> >>>> A disadvantage of any change here is that it degrades buildfarm reports, which
> >>>> recover slowly as owners upgrade to a fixed buildfarm release.  This will be
> >>>> similar to the introduction of --outputdir=output_iso.  On non-upgraded
> >>>> animals, pg_upgradeCheck failures will omit regression.diffs.

> >> Do we need to change anything in the buildfarm client to improve its
> >> response to this?  If so, seems like it might be advisable to make a
> >> buildfarm release with the upgrade before committing the change.
> >> Sure, not all owners will update right away, but if they don't even
> >> have the option then we're not in a good place.
> >
> > It would have been convenient if, for each test target, PostgreSQL code
> > decides the list of interesting log files and presents that list for the
> > buildfarm client to consume.  It's probably overkill to redesign that now,
> > though.  I also don't think it's of top importance to have unbroken access to
> > this regression.diffs, because defects that cause this run to fail will
> > eventually upset "install-check-C" and/or "check".  Even so, it's fine to
> > patch the buildfarm client in advance of the postgresql.git change:
> >
> > diff --git a/PGBuild/Modules/TestUpgrade.pm b/PGBuild/Modules/TestUpgrade.pm

> I'll commit this or something similar, but I generally try not to make
> new releases more frequently than once every 3 months, and it's only six
> weeks since the last release. So unless there's a very good reason I am
> not planning on a release before February.

There's no rush; I don't recall other reports of the spurious failure
described in the original post.  I'll plan to push the postgresql.git change
around 2019-03-31, so animals updating within a month of release will have no
degraded pg_upgradeCheck failure reports.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Unified logging system for command-line programs
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Removing --disable-strong-random from the code