| 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
| 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. |