Re: Re: [HACKERS] PATCH: enabling parallel execution for cursors explicitly (experimental)

Hi Tomas,

On 1/22/18 7:05 AM, Amit Kapila wrote:
> 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?

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
david(at)pgmasters(dot)net