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 по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: Map WAL segment files on PMEM as WAL buffers
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Bugs in pgoutput.c