Re: Commit Sequence Numbers and Visibility

On Wed, 2026-06-10 at 14:19 +0200, Matthias van de Meent wrote:
> Our current snapshot mechanism allows it to be a decision that the
> committing transaction makes (+ edge cases related to cancellation
> etc.);

That's true, but I thought that was considered to be incidental and
undesirable behavior.

>
>
> visibility is determined (and logged)
> separately from durability,

That stretches the definition of "CSN". We'd have to redefine "commit"
to mean "when the transaction writes the commit-visibility record". But
crash recovery and failover would be using a different definition?

> in which case it could be made to work by
> requiring transactions with higher durability expectations to log
> their visibility, or offloading that visibility-logging job to a
> background process.
>
> It doesn't even have to be very fancy; including the durability
> requirement in the commit record, and then logging the 3 commit
> durability horizons every once in a short while for as long as there
> are commits waiting for durability (and actually become durable)
> should be sufficient - such a "durability horizons" record should be
> sufficient as CSN (visibility horizon) for the differently-durable
> commits that were logged ahead of their respective durability
> horizon.
> It'd be comparable to the commit_delay system that combines commits'
> fsyncs, but with an additional XLog record getting logged.

If I understand your proposal:

Naively, each committing transaction can write an additional commit-
visibility record right before ProcArrayEndTransaction(), but that
could be expensive.

You are suggesting an optimization to infer the visibility LSN of a
given transaction from its commit record (including an extra durability
requirement setting) along with some other records in the WAL that are
written less often than every commit. Can you describe in more detail
what will be logged and how you make the inference?

Also, how do you choose the CSN when acquiring a snapshot? I assume
just the insert pointer?
>

> [...]
> > SERIALIZABLE:
> >
> > I didn't fully analyze the implications for SSI yet, but I believe
> > it's
> > compatible. Snapshots are still snapshots, and SSI can still detect
> > conflicts the same way as before. The serializable order can be
> > different from CSN order, which could be confusing, but that's an
> > existing problem.
>
> Do you have a reference where I can read up on this issue?

https://arxiv.org/pdf/1208.4179

Regards,
Jeff Davis