Xlog_insert_hook(NULL)"as all the throttling logic required is the current flush position which can be obtained from > XLogInsert in my opinion is the best place to call it and the hook can be something like this "void > On Fri, at 3:27 AM SATYANARAYANA NARLAPURAM wrote: This feature is useful particularly in the disaster recovery setups where primary and standby are in different regions and synchronous replication can't be set up for latency and performance reasons yet requires some level of RPO enforcement. > I am considering implementing RPO (recovery point objective) enforcement feature for Postgres where the WAL writes on the primary are stalled when the WAL distance between the primary and standby exceeds the configured (replica_lag_in_bytes) threshold. On Thu, at 2:47 AM Bharath Rupireddy wrote: The server doesn't have any hooks in XLogInsert or some other area. Replication slots etc, but the RPO enforcement may not be immediate as The hook) which doesn't require any connections to the server yet canĪccess the required info primary current_wal_lsn, restart_lsn of the This feature can also be implemented as an extension (without Primary, this requires the connections to the server and proper access Restart_lsn using pg_replication_slot, if they differ by certainĪmount, then issue ALTER SYSTEM SET READ ONLY command on the
The postgres, a simple implementation could be - get the primaryĬurrent wal lsn using pg_current_wal_lsn and all the replicas Having said all, the RPO feature can also be implemented outside of It and what parameters it should take as input (or what info it shouldĮmit out of the server via the hook) are important too. The hook can help to achieve the above objectives but where to place > Transactional log rate governance - useful for cloud providers to provide SKU sizes based on allowed WAL writes. > Enforcing rate limit and slow throttling when sync standby is falling behind (could be flush lag or replay lag) > A few other scenarios I can think of with the hook are: Should do as little work as possible, otherwise the write operations If we were to have the hook in XLogInsert which getsĬalled so frequently or XLogInsert is a hot-path, the hook really Messages, inform some service layer of the replicas falling behind the Implements this hook which can block writes on primary, write some log
Implementations (for instance they can write an extension that Reasonable so that the postgres vendors can provide different IMHO, this feature may not be needed by everyone, the hook-way seems > If this is not something we don't want to do in the core, at least adding a hook for XlogInsert is of great value. Like the "recovery_target" param with different options name, xid, I think it's good to have the usersĬhoose what the "falling behind" means for them. The "falling behind" can also be quantified by the number of We can calculate the max lag by iterating over Thecaller until the lag is less than the threshold value. > The idea here is to calculate the lag between the primary and the standby (Async?) server during XLogInsert and block If the replicas fall behind the primary for a certain period of time? This is not a problem if the applications Times and blocking writes on the primary may stop applications failingįor these transient times. The replicas can fall behind transiently at However, blocking writes on primary seemsĪn extremely radical idea. Standbyare in different regions and synchronous replication can't be set up for latency and performance reasons yet This feature is useful particularly in the disaster recovery setups where primary and Theprimary are stalled when the WAL distance between the primary and standby exceeds the configured > I am considering implementing RPO (recovery point objective) enforcement feature for Postgres where the WAL writes on On Thu, at 5:53 AM SATYANARAYANA NARLAPURAM
0 kommentar(er)
