Hi, On 2020-04-10 17:17:10 -0400, Tom Lane wrote: > > ISTM that we can make it BEGIN AFTER 'xx/xx' or such, which'd not > > require any keywords, it'd be easier to use than a procedure. > > I still don't see a good argument for tying this to BEGIN. If it > has to be a statement, why not a standalone statement?
Because the goal is to start a transaction where a certain action from the primary is visible. I think there's also some advantages of having it in a single statement for poolers. If a pooler analyzes BEGIN AFTER 'xx/xx' it could e.g. redirect the transaction to a node that's caught up far enough, instead of blocking. But that can't work even close to as easily if it's something that has to be executed before transaction begin. > (I also have a lurking suspicion that this shouldn't be SQL at all > but part of the replication command set.) Hm? I'm not quite following. The feature is useful to achieve read-your-own-writes consistency. Consider Primary: INSERT INTO app_users ...; SELECT pg_current_wal_lsn(); Standby: BEGIN AFTER 'returned/lsn'; Standby: SELECT i_am_a_set_of_very_expensive_queries FROM ..., app_users; without the AFTER/WAIT whatnot, you cannot rely on the insert having been replicated to the standby. Offloading queries from the write node to replicas is a pretty standard technique for scaling out databases (including PG). We just make it harder than necessary. How would this be part of the replication command set? This shouldn't require replication permissions for the user executing the queries. While I'm in favor of merging the replication protocol entirely with the normal protocol, I've so far received very little support for that proposition... Greetings, Andres Freund
