On Fri, May 15, 2020 at 12:19 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > My sense is that it would be a lot more sensible to do it at the > > *beginning* of the parallel operation. Once we do it once, we > > shouldn't ever do it again; that's how it works now. Deferring it > > until later seems much more likely to break things. > > AFAIU, we always increment the command counter after executing the > command. Why do we want to do it differently here?
Hmm, now I'm starting to think that I'm confused about what is under discussion here. Which CommandCounterIncrement() are we talking about here? > First, let me clarify the CTID I have used in my email are for the > table in which insertion is happening which means FK table. So, in > such a case, we can't have the same CTIDs queued for different > workers. Basically, we use CTID to fetch the row from FK table later > and form a query to lock (in KEY SHARE mode) the corresponding tuple > in PK table. Now, it is possible that two different workers try to > lock the same row of PK table. I am not clear what problem group > locking can have in this case because these are non-conflicting locks. > Can you please elaborate a bit more? I'm concerned about two workers trying to take the same lock at the same time. If that's prevented by the buffer locking then I think it's OK, but if it's prevented by a heavyweight lock then it's not going to work in this case. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
