On Wed, Nov 19, 2014 at 8:56 PM, Robert Haas <robertmh...@gmail.com> wrote: > > On Tue, Nov 18, 2014 at 8:53 AM, Amit Kapila <amit.kapil...@gmail.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
