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