Re: SERIALIZABLE can commit write skew after SSI summarization

Hi Andrey,

> > 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?

Patch v1 needed a rebase. I reproduced the bug and verified that the
patch fixes it. All in all v1 looks good to me.

--
Best regards,
Aleksander Alekseev