Re: pgsql: Un-break parallel pg_upgrade. - Mailing list pgsql-committers

From Catalin Iacob
Subject Re: pgsql: Un-break parallel pg_upgrade.
Date
Msg-id CAHg_5grr10KBZZCvm7HQaS8+5bHkPWFMAv_u0QM2E3-ohTfhmw@mail.gmail.com
Whole thread Raw
In response to pgsql: Un-break parallel pg_upgrade.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
On Sun, Feb 25, 2018 at 11:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Un-break parallel pg_upgrade.
> This is the cause of the intermittent failures buildfarm member jacana
> has been showing for the last month; evidently it is the only BF member
> configured to run the pg_upgrade test with parallelism enabled.

Seeing this I've looked at how jacana does it and configured my animal
(katydid) to set PG_UPGRADE_OPTS to '-j 4'. I did a bunch of test runs
of the tree just before this commit and confirmed that the pg_upgrade
test fails like jacana did, with this commit I saw no failure.

I imagine it would be valuable to better document these kinds of test
options (PG_UPGRADE_OPTS, EXEC_BACKEND, CLOBBER_CACHE_ALWAYS etc.) for
buildfarm owners. That might trigger owners to add some to their
animal and therefore increase diversity and coverage. Without some
docs, non core developers that do run animals will not know about
them. The build farm config script has some docs in the form of
commented out options and some text describing them, would it be worth
adding more options there? PG_UPGRADE_OPTS => '-j 4' would then be a
commented out example in the build_env setting.


pgsql-committers by date:

Previous
From: Robert Haas
Date:
Subject: pgsql: For partitionwise join, match on partcollation,not parttypcoll.
Next
From: Tom Lane
Date:
Subject: pgsql: Remove restriction on SQL block length in isolationtesterscanne