Horton

Re: Parallel execution and prepared statements

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Albe Laurenz <laurenz.albe@wien.gv.at>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "t.bussmann@gmx.net" <t.bussmann@gmx.net>
Date: 2016-11-18T21:15:31Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Enable parallelism for prepared statements and extended query protocol.

On Fri, Nov 18, 2016 at 8:21 AM, Albe Laurenz <laurenz.albe@wien.gv.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