Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
> Let's have two sequence numbers for each transaction: prepareSeqNo
> and commitSeqNo. prepareSeqNo is assigned when a transaction is
> prepared (in PreCommit_CheckForSerializableConflicts), and
> commitSeqNo is assigned when it's committed (in
> ReleasePredicateLocks). They are both assigned from one counter,
> LastSxactCommitSeqNo, so that is advanced twice per transaction,
> and prepareSeqNo is always smaller than commitSeqNo for a
> transaction. Modify operations that currently use commitSeqNo to
> use either prepareSeqNo or commitSeqNo, so that we err on the safe
> side.
>
> That yields a much smaller patch (attached). How does this look to
> you, am I missing anything?
Very clever. I'll need to study this and think about it. I'll try
to post a response before I go to bed tonight. Hopefully Dan can
weigh in, too. (I know he was traveling with limited Internet
access -- not sure about his return date.)
-Kevin