postgres_fdw vs. force_parallel_mode on ppc - Mailing list pgsql-hackers

From Noah Misch
Subject postgres_fdw vs. force_parallel_mode on ppc
Date
Msg-id 20160215225231.GA381754@tornado.leadboat.com
Whole thread Raw
In response to Re: a raft of parallelism-related bug fixes  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: postgres_fdw vs. force_parallel_mode on ppc
Re: postgres_fdw vs. force_parallel_mode on ppc
List pgsql-hackers
On Mon, Feb 08, 2016 at 02:49:27PM -0500, Robert Haas wrote:
> Well, what I've done is push into the buildfarm code that will allow
> us to do *the most exhaustive* testing that I know how to do in an
> automated fashion. Which is to create a file that says this:
>
> force_parallel_mode=regress
> max_parallel_degree=2
>
> And then run this: make check-world TEMP_CONFIG=/path/to/aforementioned/file
>
> Now, that is not going to find bugs in the deadlock.c portion of the
> group locking patch, but it's been wildly successful in finding bugs
> in other parts of the parallelism code, and there might well be a few
> more that we haven't found yet, which is why I'm hoping that we'll get
> this procedure running regularly either on all buildfarm machines, or
> on some subset of them, or on new animals that just do this.

I configured a copy of animal "mandrill" that way and launched a test run.
The postgres_fdw suite failed as attached.  A manual "make -C contrib
installcheck" fails the same way on a ppc64 GNU/Linux box, but it passes on
x86_64 and aarch64.  Since contrib test suites don't recognize TEMP_CONFIG,
check-world passes everywhere.

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Clock with Adaptive Replacement
Next
From: Tom Lane
Date:
Subject: Re: postgres_fdw vs. force_parallel_mode on ppc