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
