On Thu, Jan 18, 2018 at 12:59 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Jan 17, 2018 at 8:53 AM, Simon Riggs <simon@2ndquadrant.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
