On Wed, Mar 31, 2021 at 11:55 AM Markus Wanner <markus.wan...@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.
v5-0001-Ensure-to-send-a-prepare-after-we-detect-concurre.patch
Description: Binary data
