Re: [HACKERS] logical decoding of two-phase transactions

On Thu, Oct 8, 2020 at 6:14 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> So, for an ordinary transaction, rollback implies an explicit user
> action, but an abort could either be an explicit user action (ABORT;
> or ROLLBACK;) or an error. I agree that calling that case "abort"
> rather than "rollback" is better. However, the situation is a bit
> different for a prepared transaction: no error can prevent such a
> transaction from being committed. That is the whole point of being
> able to prepare transactions. So it is not unreasonable to think of
> use "rollback" rather than "abort" for prepared transactions, but I
> think it would be wrong in other cases. On the other hand, using
> "abort" for all the cases also doesn't seem bad to me. It's true that
> there is no ABORT PREPARED command at the SQL level, but I don't think
> that is very important. I don't feel wrong saying that ROLLBACK
> PREPARED causes a transaction abort.
>

So, as I understand you don't object to renaming the callback APIs for
ROLLBACK PREPARED transactions to "rollback_prepared_cb" but keeping
the "stream_abort" as such. This was what I was planning on doing.
I was just writing this up, so wanted to confirm.

regards,
Ajin Cherian
Fujitsu Australia