Re: Commit Sequence Numbers and Visibility

On Sat, 29 Aug 2026 at 20:47, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
> 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.

I don't remember the details on this. Why do we need the
transactional effects of T2 to be visible when/once we release the
locks? It seems to me that it's totally legitimate to wait for
durability only after releasing locks -- assuming that readers wait
for that same durability before they start to expose the effects of T2
to clients. Compare sync COMMIT with async COMMIT + WAIT FOR
commit_lsn (MODE 'sync_mode') - I think CSN commits could work in an
identical manner.

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

I don't think we need (the current version of) ProcArrayLock for this,
per se. We have a partitioned xlog insertion array, and if we add
information about current ongoing or past completed COMMITs in those
slots then scanning those slots should be sufficient for snapshot
acquisition. Yes, there's more work we'd have to do under the
xlog-insertion lock, but I think that's a fair and probably reasonable
trade-off.

Alternatively, there's no real reason I can think of why CSN-based
committing couldn't happen in parallel with its own partitioned lock.
We don't need a perfect point-in-time view of the proc array xids
(CSNs do that for us) and checking e.g. 16 "committer slots" for their
LSN/CSN status with atomic reads is probably still cheaper than doing
xip[] scans whilst holding the ProcArrayLock.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)