I wrote:
> (BTW, I've not yet looked to see if this needs to be back-ported.)
postgres_fdw will definitely include RestrictInfos in its fdw_private
list in 9.6. However, I've been unable to provoke a visible failure.
After some rooting around, the reason seems to be that:
1. postgres_fdw doesn't mark its plans as parallel-safe --- it doesn't
even have a IsForeignScanParallelSafe method. So you'd think that one
of its plans could never be transmitted to a parallel worker ... but:
2. Andreas' test query doesn't have the foreign scan in the main query
tree, it's in an InitPlan. 9.6 did not transmit any subplans or initplans
to parallel workers, but HEAD does. So HEAD sends the illegal structure
to the worker which spits up on trying to read a RestrictInfo.
I think the fact that we see this problem at all may indicate an
oversight in commit 5e6d8d2bbbcace304450b309e79366c0da4063e4 ("Allow
parallel workers to execute subplans"). If the worker were to actually
run the initplan, bad things would happen (the worker would create its
own remote connection, which we don't want). Now, in the problem plan
the InitPlan is actually attached to the topmost Gather, which I think
is safe because it'll be run by the master, but I wonder if we're being
careful enough about non-parallel-safe plans for initplans/subplans.
I do not think the planner tracks the locations of references to initplan
outputs carefully enough to be very sure about what it's doing here.
Also, even if the worker never actually executes the plan node, just
doing ExecInitNode on it in a parallel worker might be more than a
non-parallel-safe FDW is prepared to cope with.
Anyway, at present it doesn't look like we need this patch in 9.6.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
