Re: [PATCH] add concurrent_abort callback for output plugin - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [PATCH] add concurrent_abort callback for output plugin
Date
Msg-id CAA4eK1+V2rEDE6L2-yCbG9P37JBXUCgrzfKFb9GQgWrJANP-0A@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] add concurrent_abort callback for output plugin  (Markus Wanner <markus.wanner@enterprisedb.com>)
Responses Re: [PATCH] add concurrent_abort callback for output plugin  (Markus Wanner <markus.wanner@enterprisedb.com>)
List pgsql-hackers
On Wed, Mar 31, 2021 at 11:55 AM Markus Wanner
<markus.wanner@enterprisedb.com> wrote:
>
> On 31.03.21 06:39, Amit Kapila wrote:
> > I have slightly adjusted the comments, docs, and commit message. What
> > do you think about the attached?
>
> Thank you both, Amit and Ajin.  This looks good to me.
>
> Only one minor gripe:
>
> > +     a prepared transaction with incomplete changes, in which case the
> > +     <literal>concurrent_abort</literal> field of the passed
> > +     <literal>ReorderBufferTXN</literal> struct is set. This is done so that
> > +     eventually when the <command>ROLLBACK PREPARED</command> is decoded, there
> > +     is a corresponding prepared transaction with a matching gid.
>
> The last sentences there now seems to relate to just the setting of
> "concurrent_abort", rather than the whole reason to invoke the
> prepare_cb.  And the reference to the "gid" is a bit lost.  Maybe:
>
>     "Thus even in case of a concurrent abort, enough information is
>      provided to the output plugin for it to properly deal with the
>      <command>ROLLBACK PREPARED</command> once that is decoded."
>

Okay, Changed the patch accordingly.

-- 
With Regards,
Amit Kapila.

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Flaky vacuum truncate test in reloptions.sql
Next
From: Sait Talha Nisanci
Date:
Subject: Re: Crash in record_type_typmod_compare