Re: postgres_fdw vs. force_parallel_mode on ppc

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postgres_fdw vs. force_parallel_mode on ppc
Date: 2016-02-22 15:03:51
Message-ID: 11273.1456153431@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Feb 22, 2016 at 11:02 AM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> 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.

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

I've not looked at the test case to see if this is exactly what's
going wrong, but it's pretty easy to see how there might be a problem:
consider a STABLE user-defined function that does a SELECT from a foreign
table. If that function call gets pushed down into a parallel worker
then it would fail as described.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-02-22 15:07:37 Re: Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.
Previous Message Stephen Frost 2016-02-22 15:01:59 Re: Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.