Am 18.11.2016 um 14:21 schrieb Albe Laurenz <>:
> 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')");

Great example of mixing a v3 prepare with an simple query execute. I didn't 
think about that while even the docs state clearly: "Named prepared statements 
can also be created and accessed at the SQL command level, using PREPARE and 
EXECUTE." Sticking with either protocol version does not trigger the error. 

> I think we should either apply something like that patch or disable parallel
> execution for prepared statements altogether and document that.

So we likely need to backpatch something more then a doc-fix for 9.6. Given the 
patch proposals around, this would either disable a feature (in extended query 
protocol) or add a new one (in simple query protocol/SQL). Or would it be more 
appropriate to split the patch and use CURSOR_OPT_PARALLEL_OK in prepare.c on 
master only? I'm asking in case there is a necessity to prepare a proposal for 
an documentation patch targeting 9.6 specifically.

Best regards

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

Reply via email to