postgres_fdw vs. force_parallel_mode on ppc

Поиск
Список
Период
Сортировка
От Noah Misch
Тема postgres_fdw vs. force_parallel_mode on ppc
Дата
Msg-id 20160215225231.GA381754@tornado.leadboat.com
обсуждение исходный текст
Ответ на Re: a raft of parallelism-related bug fixes  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: postgres_fdw vs. force_parallel_mode on ppc  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: postgres_fdw vs. force_parallel_mode on ppc  (Robert Haas <robertmhaas@gmail.com>)
Список 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.

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Clock with Adaptive Replacement
Следующее
От: Tom Lane
Дата:
Сообщение: Re: postgres_fdw vs. force_parallel_mode on ppc