On 30.03.21 06:48, Ajin Cherian wrote: > For now, I've created a patch that addresses the problem reported using > the existing callbacks.
Thanks.
> Do have a look if this fixes the problem reported.
Yes, this replaces the PREPARE I would do from the concurrent_abort callback in a direct call to rb->prepare. However, it misses the most important part: documentation. Because this clearly is a surprising behavior for a transaction that's not fully decoded and guaranteed to get aborted.
Where do you suggest this be documented? From an externally visible point of view, I dont see much of a surprise.
A transaction that was prepared and rolled back can be decoded to be prepared and rolled back with incomplete changes.
