On Thu, Jun 4, 2020 at 9:10 AM Andres Freund <and...@anarazel.de> wrote: > > Hi, > > On 2020-06-04 08:10:07 +0530, Amit Kapila wrote: > > On Thu, Jun 4, 2020 at 12:09 AM Andres Freund <and...@anarazel.de> wrote: > > > > I strongly disagree with the idea of "just sync(ing) it up at the end > > > > of parallelism". That seems like a completely unprincipled approach to > > > > the problem. Either the command counter increment is important or it's > > > > not. If it's not important, maybe we can arrange to skip it in the > > > > first place. If it is important, then it's probably not OK for each > > > > backend to be doing it separately. > > > > > > That scares me too. These command counter increments definitely aren't > > > unnecessary in the general case. > > > > > > > Yeah, this is what we want to understand? Can you explain how they > > are useful here? AFAIU, heap_lock_tuple doesn't use commandid while > > storing the transaction information of xact while locking the tuple. > > But the HeapTupleSatisfiesUpdate() call does use it? >
It won't use 'cid' for lockers or multi-lockers case (AFAICS, there are special case handling for lockers/multi-lockers). I think it is used for updates/deletes. > And even if that weren't an issue, I don't see how it's defensible to > just randomly break the the commandid coherency for parallel copy. > At this stage, we are evelauating whether there is any need to increment command counter for foreign key checks or is it just happening because we are using using some common code to execute "Select ... For Key Share" statetement during these checks. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
