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
Re: postgres_fdw vs. force_parallel_mode on ppc |
Список | 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 по дате отправления: