Re: Parallel copy - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Parallel copy
Date
Msg-id 20200604034013.56gj5ygulnmhrhqb@alap3.anarazel.de
Whole thread Raw
In response to Re: Parallel copy  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Parallel copy
List pgsql-hackers
Hi,

On 2020-06-04 08:10:07 +0530, Amit Kapila wrote:
> On Thu, Jun 4, 2020 at 12:09 AM Andres Freund <andres@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?

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.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: libpq copy error handling busted
Next
From: Amit Kapila
Date:
Subject: Re: Transactions involving multiple postgres foreign servers, take 2