Re: Parallel execution and prepared statements

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "'Robert Haas *EXTERN*'" <robertmhaas(at)gmail(dot)com>
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-21 10:29:37
Message-ID: A737B7A37273E048B164557ADEF4A58B53999D50@ntex2010i.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
>> /* 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.

Is there a better, more consistent approach for that?

Yours,
Laurenz Albe

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2016-11-21 12:10:36 Re: condition variables
Previous Message Magnus Hagander 2016-11-21 10:04:05 Re: Mail thread references in commits