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
