Re: postgres_fdw vs. force_parallel_mode on ppc
От | Tom Lane |
---|---|
Тема | Re: postgres_fdw vs. force_parallel_mode on ppc |
Дата | |
Msg-id | 838.1456198304@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: postgres_fdw vs. force_parallel_mode on ppc (Thomas Munro <thomas.munro@enterprisedb.com>) |
Список | pgsql-hackers |
Thomas Munro <thomas.munro@enterprisedb.com> writes: > On Tue, Feb 23, 2016 at 4:03 AM, Tom Lane <tgl@sss.pgh.pa.us> 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
В списке pgsql-hackers по дате отправления: