Re: alternative model for handling locking in parallel groups

On Wed, Nov 19, 2014 at 8:56 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Tue, Nov 18, 2014 at 8:53 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
> > Won't this be addressed because both updates issued from myfunc()
> > are considered as separate commands, so w.r.t lock it should behave
> > as 2 different updates in same transaction. I think there may be more
> > things to make updates possible via parallel workers apart from tuple
lock.
>
> Hmm. It won't work to have different backends with different command
> counters anyway. If backend 1 is using command counter 5 and backend
> 2 is using command counter 6, then backend 2 will see its snapshot
> changing under it as backend 1 makes changes. That's not OK.
>

Right, so which means that we need to do much more than just make
lock manager changes to handle parallel WRITE operations.

> But that's not really the point. Heavyweight locks are sometimes used
> to protect pretty low-level things, like the right to update a tuple,
> or physically extend a relation by a block on disk, or split a bucket
> in a hash index. It won't be OK to just ignore the requirement of
> mutual exclusion in those cases, I think. We could of course decide
> that the parallel processes must have their own mechanism to prevent
> such conflicts apart from the lock manager, but they've got to be
> prevented somehow.
>

Agreed and I would vote for going by simple mechanism in this case
which is to prohibit any *write* operation in parallel worker.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com