Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes
От | Dilip Kumar |
---|---|
Тема | Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes |
Дата | |
Msg-id | CAFiTN-uaMm_9=s0nj=rtnmxVprKtdKwm=5uHX6bZ3di2pshnZQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On Wed, Jan 5, 2022 at 11:16 PM Andres Freund <andres@anarazel.de> wrote: > > Hi, > > On 2021-12-29 11:31:51 -0800, Andres Freund wrote: > > That's pretty much the same - XLogInsert() can trigger an > > XLogWrite()/Flush(). > > > > I think it's a complete no-go to add throttling to these places. It's quite > > possible that it'd cause new deadlocks, and it's almost guaranteed to have > > unintended consequences (e.g. replication falling back further because > > XLogFlush() is being throttled). > > I thought of another way to implement this feature. What if we checked the > current distance somewhere within XLogInsert(), but only set > InterruptPending=true, XLogDelayPending=true. Then in ProcessInterrupts() we > check if XLogDelayPending is true and sleep the appropriate time. > > That way the sleep doesn't happen with important locks held / within a > critical section, but we still delay close to where we went over the maximum > lag. And the overhead should be fairly minimal. +1, this sounds like a really good idea to me. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: