Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Kevin and Dan also pointed out that a 2PC transaction can stay
>> in prepared state for a long time, and we could optimize that by
>> setting prepareSeqNo only at the final COMMIT PREPARED. I
>> objected to that, for the reason that it's currently very
>> convenient for testing purposes that a transaction prepared with
>> PREPARE TRANSACTION is in the exact same state as regular
>> transaction that's going through regular commit processing.
>
> Seems to me there's a more fundamental reason not to do that,
> which is that once you've done PREPARE it is no longer legitimate
> to decide to roll back the transaction to get out of a "dangerous"
> structure --- ie, you have to target one of the other xacts
> involved instead. Shouldn't the assignment of a prepareSeqNo
> correspond to the point where the xact is no longer a target for
> SSI rollback?
No, it wouldn't be useful at all if we had an accurate commitSeqNo.
It's being used to bracket the moment of visibility, which with
Heikki's patch now falls between the prepareSeqNo and commitSeqNo.
The name is perhaps misleading. It's useful only for determining
what *other* transactions require rollback.
In any event, SSI will never cause a transaction to fail after it
has prepared. This patch doesn't change that, nor would the change
Dan and I suggested.
-Kevin