Re: Parallel copy

On Fri, May 15, 2020 at 12:19 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)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