On Thu, Dec 17, 2020 at 11:47 PM Amit Kapila <amit.kapil...@gmail.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.
