On Fri, Aug 28, 2026, Jeff Davis wrote: > I'm not clear on the use case where the reader needs to obey the > writer's durability setting. Why wouldn't the reader just care about > its own durability setting?
I agree. I was not proposing that the reader should obey the writer's setting. I wanted to make explicit that, with commit-record LSNs as the visibility order, a reader with a weaker policy may consume T1 while T1's COMMIT is still waiting for its writer-selected durability. > Waiting to use a snapshot is not the same as a transaction being > invisible to that snapshot. This distinction makes sense to me. Once T2 releases its locks, a new snapshot includes both T1 and T2. The reader's durability policy only determines whether it may use that snapshot immediately. This also gives the common-prefix property needed to prevent Long Fork. One implementation question still seems open to me. At Vancouver, Andres was concerned that eliminating Long Fork might require coupling WAL insertion with ProcArrayLock: the point where a transaction joins snapshot visibility must have a position in WAL, while no snapshot may pass that point without including the transaction. Is maxTransactionFinishedPtr intended to avoid that interlock by making its atomic update the snapshot linearization point? For example, if T1 has inserted its commit record at LSN 1 but has not yet made its CSN state readable, and T2 advances maxTransactionFinishedPtr to LSN 2, a snapshot at LSN 2 must include T1 rather than treat it as in progress. Is the intended solution for that snapshot to wait on T1's commit-in- progress state, or do we need another WAL-visible visibility marker? Is there any further design input you would like before implementation? Are you already planning to post a prototype? If not, I can prepare one based on Heikki's latest "CSN snapshots in hot standby" patch. Even if the interlock above is not fully settled, a prototype would make it concrete and let us measure its performance impact rather than reason about it only in the abstract. I would initially focus on the common visibility order, the Long Fork reproducer, and the relevant concurrent workloads, leaving the reader durability policy as a separate step. Thank you! Best regards, Andrey Borodin.
