MIME-Version: 1.0
References: <8e6ba982-fd41-4779-8729-eb120df69ea0@eisentraut.org>
In-Reply-To: <8e6ba982-fd41-4779-8729-eb120df69ea0@eisentraut.org>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
Date: Mon, 28 Oct 2024 18:02:30 +0100
Message-ID: <CAGECzQQJLjW5PRczzLmA8riCW4uj5i-fqVm4cpOiSDtULG4KKA@mail.gmail.com>
Subject: Re: protocol-level wait-for-LSN
To: Peter Eisentraut <peter@eisentraut.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAGECzQQJLjW5PRczzLmA8riCW4uj5i-fqVm4cpOiSDtULG4KKA%40mail.gmail.com>
Precedence: bulk

On Mon, 28 Oct 2024 at 16:51, Peter Eisentraut <peter@eisentraut.org> wrote:
> The idea is to do the equivalent of pg_wal_replay_wait() on the protocol
> level, so that it is ideally fully transparent to the application code.
> The application just issues queries, and they might be serviced by a
> primary or a standby, but there is always a correct ordering of reads
> after writes.

Sounds super useful. This came up in the Unconference session about
protocols on PGConf.dev too. I'll

> There might be other ways to slice this.  Instead of using a
> hypothetical middleware, the application would use two connections, one
> for writing, one for reading, and the LSN would be communicated between
> the two.  I imagine in this case, at least the one half of the protocol,
> shipping the current LSN with ReadyForQuery, could be useful, instead of
> requiring application code to issue pg_current_wal_insert_lsn() explicitly.

I think this usecase is already super useful by itself. And having
both directions would still be preferred I think.