Re: postgres_fdw vs. force_parallel_mode on ppc

On Tue, Feb 23, 2016 at 4:03 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

I thought user defined functions were not a problem since it's the
user's responsibility to declare functions' parallel safety correctly.
The manual says: "In general, if a function is labeled as being safe
when it is restricted or unsafe, or if it is labeled as being
restricted when it is in fact unsafe, it may throw errors or produce
wrong answers when used in a parallel query"[1]. Uncommitted changes
on foreign tables are indeed invisible to functions declared as
PARALLEL SAFE, when run with force_parallel_mode = on,
max_parallel_degree = 2, but the default is UNSAFE and in that case
the containing query is never parallelised. Perhaps the documentation
could use a specific mention of this subtlety with FDWs in the
PARALLEL section?

The case of a plain old SELECT (as seen in the failing regression
test) is definitely a problem though and FDW access there needs to be
detected automatically. I also thought that
has_parallel_hazard_walker might be the right place for that logic, as
you suggested in your later message.

[1] http://www.postgresql.org/docs/devel/static/sql-createfunction.html

--
Thomas Munro
http://www.enterprisedb.com