Re: [HACKERS] logical decoding of two-phase transactions

From: Ajin Cherian <itsajin(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Date: 2020-09-28 09:01:35
Message-ID: CAFPTHDY-yPVNJawNR1bvOj4re7o5SzYsGkyLMD-Nqr6CmThvdQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 28, 2020 at 6:36 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, Sep 28, 2020 at 1:13 PM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
> >
> > On Wed, Sep 23, 2020 at 2:39 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > I have added a new patch for supporting 2 phase commit semantics in
> > the streaming APIs for the logical decoding plugins. I have added 3
> > APIs
> > 1. stream_prepare
> > 2. stream_commit_prepared
> > 3. stream_abort_prepared
> >
> > I have also added the support for the new APIs in test_decoding
> > plugin. I have not yet added it to pgoutpout.
> >
> > I have also added a fix for the error I saw while calling
> > ReorderBufferCleanupTXN as part of FinishPrepared handling. As a
> > result I have removed the function I added earlier,
> > ReorderBufferCleanupPreparedTXN.
> >
>
> Can you explain what was the problem and how you fixed it?

When I added the changes for cleaning up tuplecids in
ReorderBufferTruncateTXN, I was not deleting it from the list
(dlist_delete), only calling ReorderBufferReturnChange to free
memory. This logic was copied from ReorderBufferCleanupTXN, there the
lists were all cleaned up in the end, so was not present in each list
cleanup logic.

>
> > Please have a look at the new changes and let me know what you think.
> >
> > I will continue to look at:
> >
> > 1. Remove snapshots on prepare truncate.
> > 2. Bug seen while abort of prepared transaction, the prepared flag is
> > lost, and not able to make out that it was a previously prepared
> > transaction.
> >
>
> And the support of new APIs in pgoutput, right?

Yes, that also.

regards,
Ajin Cherian
Fujitsu Australia

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2020-09-28 09:14:39 Re: calling procedures is slow and consumes extra much memory against calling function
Previous Message k.jamison@fujitsu.com 2020-09-28 08:57:36 RE: [Patch] Optimize dropping of relation buffers using dlist