Thomas Munro <> writes:
> On Tue, Feb 23, 2016 at 4:03 AM, Tom Lane <> wrote:
>> 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].

Hm.  I'm not terribly happy with this its-the-users-problem approach to
things, mainly because I have little confidence that somebody couldn't
figure out a security exploit based on it.

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

Yes, the problem we're actually seeing in that regression test is not
dependent on a function wrapper.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to