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.
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 |