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

On Thu, Dec 17, 2020 at 11:47 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> I went ahead and used both origin_lsn and origin_timestamp to avoid
> the possibility of a match of prepared xact from two different nodes.
> We can handle this at begin_prepare and prepare time but we don't have
> prepare_lsn and prepare_timestamp at rollback_prepared time, so what
> do about that? As of now, I am using just GID at rollback_prepare time
> and that would have been sufficient if we always receive prepare
> before rollback because at prepare time we would have checked
> origin_lsn and origin_timestamp. But it is possible that we get
> rollback prepared without prepare in case if prepare happened before
> consistent_snapshot is reached and rollback happens after that. For
> commit-case, we do send prepare and all the data at commit time in
> such a case but doing so for rollback case doesn't sound to be a good
> idea. Another possibility is that we send prepare_lsn and prepare_time
> in rollback_prepared API to deal with this. I am not sure if it is a
> good idea to just rely on GID in rollback_prepare. What do you think?

Thinking about it for some time, my initial reaction was that the
distributed servers should maintain uniqueness of GIDs and re-checking
with LSNs is just overkill. But thinking some more, I realise that
since we allow reuse of GIDs, there could be a race condition where a
previously aborted/committed txn's GID was reused
which could lead to this. Yes, I think we could change
rollback_prepare to send out prepare_lsn and prepare_time as well,
just to be safe.

regards,
Ajin Cherian
Fujitsu Australia.