Re: Parallel execution and prepared statements
От | Robert Haas |
---|---|
Тема | Re: Parallel execution and prepared statements |
Дата | |
Msg-id | CA+TgmoaNU=oZbVYhy7L2nYjcpGpDLQU8tvRE9iH13wSYrroCEA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel execution and prepared statements (Albe Laurenz <laurenz.albe@wien.gv.at>) |
Ответы |
Re: Parallel execution and prepared statements
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: