Hi Bharath, On Fri, Jan 27, 2023 at 12:04 PM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote: > > On Fri, Jan 27, 2023 at 2:03 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote: > > > > On 2023-Jan-27, Bharath Rupireddy wrote: > > > > > Looking at the patch, the feature, in its current shape, focuses on > > > improving replication lag (by throttling WAL on the primary) only when > > > synchronous replication is enabled. Why is that? Why can't we design > > > it for replication in general (async, sync, and logical replication)? > > > > > > Keeping replication lag under check enables one to provide a better > > > RPO guarantee
Sorry for not answering earlier; although the title of the thread goes for the SyncRep-only I think everyone would be open to also cover the more advanced async scenarios that Satyanarayana proposed in those earlier threads (as just did Simon much earlier). I was proposing wal_throttle_larger_transactions=<..> (for the lack of better name), however v2 of the patch from today right now contains again reference to syncrep (it could be changed of course). It's just the code that is missing that could be also added on top of v2, so we could combine our efforts. It's just the competency and time that I lack on how to implement such async-scenario code-paths (maybe Tomas V. has something in mind with his own words [1]) so also any feedback from senior hackers is more than welcome ... -J. [1] - "The solution I've imagined is something like autovacuum throttling - do some accounting of how much "WAL bandwidth" each process consumed, and then do the delay/sleep in a suitable place. "
