Re: Commit Sequence Numbers and Visibility

On Mon, 2026-08-31 at 16:23 +0200, Matthias van de Meent wrote:
> > 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?

The effects of T2 must be included in any snapshot acquired after T2
releases locks. Applications use LOCK TABLE, SELECT ... FOR UPDATE,
etc., to serialize transactions, and that would all break if constraint
(c) doesn't hold.

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

IIUC, you are making a slightly different point, which is that
"visible" can have a slightly different definition than "included in
the snapshot". That's true, if by "visible" you mean "externally
visible", that can happen at some later point after the snapshot has
already been acquired. The conditions for external visibility (e.g.
whether it requires the transaction to be durable first, or not) should
be definable by the reader without changing the set of transactions a
snapshot represents.

>   Compare sync COMMIT with async COMMIT + WAIT FOR
> commit_lsn (MODE 'sync_mode') - I think CSN commits could work in an
> identical manner.

I agree that we may want to unify those paths a bit more. In
particular, we may have to update CLOG and CSNLOG before flushing WAL
in the sync path, just like it does in the async path.

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

I'll have to analyze this a bit more. I am more concerned about the
coupling than the performance, but you may be right.

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

Interesting. I'll have to think about that, too.

Regards,
Jeff Davis