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.
