Re: [PATCH] add concurrent_abort callback for output plugin
Markus Wanner <markus.wanner@enterprisedb.com>
From: Markus Wanner <markus.wanner@enterprisedb.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Ajin Cherian <itsajin@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-30T09:54:31Z
Lists: pgsql-hackers
On 30.03.21 11:02, Amit Kapila wrote: > On Tue, Mar 30, 2021 at 12:00 PM Markus Wanner >> Yes, this replaces the PREPARE I would do from the concurrent_abort >> callback in a direct call to rb->prepare. > > Because concurrent_abort() > internally trying to prepare transaction seems a bit ugly and not only > that if we want to go via that route, it needs to distinguish between > rollback to savepoint and rollback cases as well. Just to clarify: of course, the concurrent_abort callback only sends a message to the subscriber, which then (in our current implementation) upon reception of the concurrent_abort message opts to prepare the transaction. Different implementations would be possible. I would recommend this more explicit API and communication over hiding the concurrent abort in a prepare callback. Regards Markus
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