On Tue, Feb 16, 2016 at 12:12 PM, Noah Misch <noah@leadboat.com> wrote:
> On Mon, Feb 15, 2016 at 06:07:48PM -0500, Tom Lane wrote:
>> Noah Misch <noah@leadboat.com> writes:
>> > 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.
>>
>> Hm, is this with or without the ppc-related atomics fix you just found?
>
> Without those. The ppc64 GNU/Linux configuration used gcc, though, and the
> atomics change affects xlC only. Also, the postgres_fdw behavior does not
> appear probabilistic; it failed twenty times in a row.
The postgres_fdw failure is a visibility-of-my-own-uncommitted-work
problem. The first command in a transaction updates a row via an FDW,
and then the SELECT expects to see the effects, but when run in a
background worker it creates a new FDW connection that can't see the
uncommitted UPDATE.
I wonder if parallelism of queries involving an FDW should not be
allowed if your transaction has written through the FDW.
--
Thomas Munro
http://www.enterprisedb.com