Horton

Re: Parallel copy

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>, Ants Aasma <ants@cybertec.at>, vignesh C <vignesh21@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Alastair Turner <minion@decodable.me>, Thomas Munro <thomas.munro@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-06-04T04:51:58Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow WaitLatch() to be used without a latch.

  2. Add %P to log_line_prefix for parallel group leader

  3. Include replication origins in SQL functions for commit timestamp

  4. Avoid useless buffer allocations during binary COPY FROM.

On Thu, Jun 4, 2020 at 9:10 AM Andres Freund <andres@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 <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?
>

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