On Sat, 29 Aug 2026 at 20:47, Andrey Borodin <[email protected]> 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)
