Re: SERIALIZABLE can commit write skew after SSI summarization

Hi Jacob,

> once session 2's SIREAD locks move to virtualtransaction = '-1/0',
> session 1 commits and the final count is 2.

I reproduced this. The overlap test in CheckTargetForConflictsIn() uses
finishedBefore for a committed transaction. OldCommittedSxact has no
valid finishedBefore, so the test ignores its predicate locks.

Each summarized predicate lock already stores the latest commitSeqNo
among the transactions folded into it. PFA a tentative patch set which
compares that with lastCommitBeforeSnapshot. A later commit means that
at least one reader represented by the lock overlapped the writer.

The first patch adds a deterministic injection-point test, and the
second adds the fix.

I have two buildfarm animals available for unusual configurations. One
currently runs with WAL consistency checking, and the other checks WAL
compatibility with a zero release version. I could enable
TEST_SUMMARIZE_SERIAL on one of them. I had seen a related false
negative while trying different modes around the Jepsen report, but did
not pursue it then. Your report made me return to it. I am not sure
whether the existing check-world schedules would have exposed this bug.
Would permanently testing this mode be useful, and is there any reason
not to do that?

Thank you!

Best regards, Andrey Borodin.