| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | jeremy(at)musicsmith(dot)net, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel plan |
| Date: | 2020-06-12 18:13:11 |
| Message-ID: | CA+TgmoZvR9SP5mzH1k7MYrv3y1z4dWoJGz2z2SU-Qo1B7LrdgA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Sat, Mar 21, 2020 at 11:23 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I think that the latter restriction is probably sane, because we don't
> want to suspend execution of a parallel query while we've got worker
> processes waiting.
Right.
> And there might be some implementation restrictions
> lurking under it too --- that's not a part of the code I know in any
> detail.
There are. When you EnterParallelMode(), various normally-permissible
options are restricted and will error out (e.g. updating your snapshot
or command ID). Parallel query's not safe unless you remain in
parallel mode from start to finish, but that means you can't let
control escape into code that might do arbitrary things. That in a
nutshell is why the cursor restriction is there.
This is a heck of a nice improvement. Thanks for working on it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2020-06-12 19:43:19 | Re: BUG #16492: DROP VIEW IF EXISTS error |
| Previous Message | PG Bug reporting form | 2020-06-12 17:47:12 | BUG #16492: DROP VIEW IF EXISTS error |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-06-12 18:14:43 | Re: Infinities in type numeric |
| Previous Message | Andrew Gierth | 2020-06-12 18:02:37 | Re: Infinities in type numeric |