On Mon, 28 Oct 2024 at 16:51, Peter Eisentraut <pe...@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.
