Robert Haas wrote: > On Tue, Nov 15, 2016 at 10:41 AM, Albe Laurenz <laurenz.a...@wien.gv.at> > wrote: >> Tobias Bussmann has discovered an oddity with prepared statements. >> >> Parallel scan is used with prepared statements, but only if they have >> been created with protocol V3 "Parse". >> If a prepared statement has been prepared with the SQL statement PREPARE, >> it will never use a parallel scan. >> >> I guess that is an oversight in commit 57a6a72b, right? >> PrepareQuery in commands/prepare.c should call CompleteCachedPlan >> with cursor options CURSOR_OPT_PARALLEL_OK, just like >> exec_prepare_message in tcop/postgres.c does. >> >> The attached patch fixes the problem for me. > > Actually, commit 57a6a72b made this change, and then 7bea19d0 backed > it out again because it turned out to break things.
I didn't notice the CREATE TABLE ... AS EXECUTE problem. But then the change to use CURSOR_OPT_PARALLEL_OK in tcop/postgres.c should be reverted as well, because it breaks things just as bad: /* creates a parallel-enabled plan */ PQprepare(conn, "pstmt", "SELECT id FROM l WHERE val = $1", 1, NULL); /* blows up with "cannot insert tuples during a parallel operation" */ PQexec(conn, "CREATE TABLE bad(id) AS EXECUTE pstmt('abcd')"); With Tobias' patch, this does not fail. I think we should either apply something like that patch or disable parallel execution for prepared statements altogether and document that. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers