Re: Parallel execution and prepared statements

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "t(dot)bussmann(at)gmx(dot)net" <t(dot)bussmann(at)gmx(dot)net>
Subject: Re: Parallel execution and prepared statements
Date: 2016-11-18 21:15:31
Message-ID: CA+TgmoaNU=oZbVYhy7L2nYjcpGpDLQU8tvRE9iH13wSYrroCEA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 18, 2016 at 8:21 AM, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> wrote:
> 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')");

Ouch. I missed that.

> 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.

I agree. I think probably the first option is better, but I might
have to commit with one hand so I can hold my nose with the other.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-11-18 21:28:36 Re: [RFC] Should we fix postmaster to avoid slow shutdown?
Previous Message Alvaro Herrera 2016-11-18 21:14:53 Re: [RFC] Should we fix postmaster to avoid slow shutdown?