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.
v1-0001-Test-SSI-conflict-detection-after-summarization.patch
Description: Binary data
v1-0002-Detect-SSI-conflicts-with-summarized-predicate-lo.patch
Description: Binary data
