Re: postgres_fdw vs. force_parallel_mode on ppc

On Mon, Feb 22, 2016 at 11:02 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Tue, Feb 16, 2016 at 12:12 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> On Mon, Feb 15, 2016 at 06:07:48PM -0500, Tom Lane wrote:
>>> Noah Misch <noah(at)leadboat(dot)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.

Foreign tables are supposed to be categorically excluded from
parallelism. Not sure why that's not working in this instance.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company