From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] PATCH: enabling parallel execution for cursors explicitly (experimental) |
Date: | 2018-01-22 12:05:29 |
Message-ID: | CAA4eK1+dnTqRENy9f5Tha3D3zcWtSWfxOHW4L9u9gWtb15eRnw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 18, 2018 at 12:59 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Jan 17, 2018 at 8:53 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> Or we could go the other way and try to keep the workers running. I
> don't really like that because it ties down those workers for
> potentially a long period of time, but that might be acceptable for
> some users. The main implementation problem is that somehow we'd need
> to propagate to them an updated version of any state that has changed
> while the query was suspended, such as new combo CIDs that have been
> created in the meantime. dshash seems like a useful tool toward such
> a goal, but there are details to work out, and there are similar
> problems with everything else that is copied from leader to workers.
> We could possibly prevent these problems from arising by placing
> draconian restrictions on what a backend is allowed to do while a
> parallel cursor is open, such as in your follow-on proposal to lock
> out everything except FETCH. I'm not really that excited about such a
> thing because it's extremely limiting and still doesn't solve all the
> problems: in particular, after BEGIN ... DECLARE CURSOR PARALLEL ...
> FETCH ... FETCH ... syntax error, there is going to be trouble around
> the state of group locking. It will be very bad if the workers think
> the transaction is still alive and the leader thinks it is in a new
> transaction and they're all sharing locks.
>
On error, workers should be terminated. What kind of problem do you
have in mind?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-01-22 12:39:03 | Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status) |
Previous Message | Amit Kapila | 2018-01-22 11:52:32 | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |