Re: Commit Sequence Numbers and Visibility

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.