From: | Tobias Bussmann <t(dot)bussmann(at)gmx(dot)net> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Robert Haas *EXTERN* <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Parallel execution and prepared statements |
Date: | 2016-11-21 16:24:55 |
Message-ID: | 31E54FA6-F54C-4EDA-8D39-E3F0FC6B297E@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Am 18.11.2016 um 14:21 schrieb Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>:
> 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
Tobias
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-11-21 16:26:18 | Re: [sqlsmith] Parallel worker crash on seqscan |
Previous Message | Tom Lane | 2016-11-21 16:00:58 | Re: [sqlsmith] Failed assertion in parallel worker in ExecInitSubPlan |