On Tue, Feb 23, 2016 at 4:03 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Feb 22, 2016 at 11:02 AM, Thomas Munro >> <thomas.mu...@enterprisedb.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
