Hi Tomas, On 1/22/18 7:05 AM, Amit Kapila wrote: > 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?
Since there appears to be an ongoing discussion about how this patch should work I am marking it Returned with Feedback for this CF. Regards, -- -David da...@pgmasters.net
