Re: Parallel Append subplan order instability on aye-aye

Noah Misch <noah@leadboat.com>

From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-06-05T05:00:37Z
Lists: pgsql-hackers
On Mon, May 20, 2019 at 11:15:47PM -0400, Tom Lane wrote:
> I got around to excavating in the buildfarm archives, and found a round
> dozen of more-or-less-similar incidents.  I went back 18 months, which
> by coincidence (i.e., I didn't realize it till just now) is just about
> the time since 624e440a:
> 
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=francolin&dt=2018-01-14%2006%3A30%3A02
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2018-03-02%2011%3A30%3A19
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin&dt=2018-03-11%2023%3A25%3A46
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin&dt=2018-03-15%2000%3A02%3A04
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=spurfowl&dt=2018-04-05%2003%3A22%3A05
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=desmoxytes&dt=2018-04-07%2018%3A32%3A02
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=termite&dt=2018-04-08%2019%3A55%3A06
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=damselfly&dt=2018-04-23%2010%3A00%3A15
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=piculet&dt=2019-04-19%2001%3A50%3A08
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2019-04-23%2021%3A23%3A12
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer&dt=2019-05-14%2014%3A59%3A43
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=aye-aye&dt=2019-05-19%2018%3A30%3A10

> * All the failures are in the pg_upgrade test (and some are before,
> some after, we switched that from serial to parallel schedule).
> This makes very little sense; how is that meaningfully different
> from the buildfarm's straight-up invocations of "make check" and
> "make installcheck"?

Two behaviors are unique to pg_upgrade's check and have been in place since
2018-01-14.  It uses "initdb --wal-segsize 1".  It creates three additional
databases, having long names.  Neither of those is clearly meaningful in this
context, but it would be a simple matter of programming to make pg_regress.c
do those things and see if the buildfarm starts witnessing this failure mode
outside the pg_upgrade check.



Commits

  1. ANALYZE a_star and its children to avoid plan instability in tests.

  2. Finish reverting "Insert temporary debugging output in regression tests."

  3. Partially revert "Insert temporary debugging output in regression tests."

  4. Insert temporary debugging output in regression tests.

  5. Improve the heuristic for ordering child paths of a parallel append.