Re: protocol-level wait-for-LSN

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: protocol-level wait-for-LSN
Date: 2024-10-28 17:02:30
Message-ID: CAGECzQQJLjW5PRczzLmA8riCW4uj5i-fqVm4cpOiSDtULG4KKA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 28 Oct 2024 at 16:51, Peter Eisentraut <peter(at)eisentraut(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2024-10-28 17:06:01 Should we support casting between ARRAYs and JSON(B)?
Previous Message Heikki Linnakangas 2024-10-28 16:58:08 Re: protocol-level wait-for-LSN