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