Re: [PATCH] add concurrent_abort callback for output plugin
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Markus Wanner <markus.wanner@enterprisedb.com>
Cc: Ajin Cherian <itsajin@gmail.com>, Markus Wanner <markus@bluegap.ch>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-31T13:18:49Z
Lists: pgsql-hackers
Attachments
- v5-0001-Ensure-to-send-a-prepare-after-we-detect-concurre.patch (application/octet-stream) patch v5-0001
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.
Commits
-
Avoid sending prepare multiple times while decoding.
- f25a4584c6f5 14.0 landed
-
Ensure to send a prepare after we detect concurrent abort during decoding.
- 4778826532a6 14.0 landed