Re: Commit Sequence Numbers and Visibility

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: pgsql-hackers mailing list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Commit Sequence Numbers and Visibility
Date: 2026-09-01 00:45:30
Message-ID: 0e6709a968bc8a627fef14fdda13785f42a25b73.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

I think I misunderstood this point the first time around. Are you
saying that we can essentially make every transaction an async
transaction, as long as we flush before we return the results to the
client?

I hadn't thought of it that way, but you're right: if we say that
readers define the durability level they expect for the data they read,
then what you say is a natural consequence. And the writers only care
about the durability level because they are readers, too, in that they
need to send a message to the client indicating that the commit was
successful.

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2026-09-01 01:08:44 Re: Disallow outer-level and WHERE-clause aggregates in GRAPH_TABLE
Previous Message Jeff Davis 2026-09-01 00:33:03 Re: Commit Sequence Numbers and Visibility