Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes
От | Bharath Rupireddy |
---|---|
Тема | Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes |
Дата | |
Msg-id | CALj2ACU=Bc6YbwxKpA9L_crN7=Vtay4kesxjWU930iABV6MFCQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes
|
Список | pgsql-hackers |
On Thu, Dec 30, 2021 at 1:21 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > On Thu, Dec 30, 2021 at 12:36 PM SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> wrote: >>> >>> >>> Yeah, I think that would make sense, even though we will be allowing a new backend to get connected insert WAL, and getcommitted but after that, it will be throttled. However, if the number of max connections will be very high then evenafter we detected a lag there a significant amount WAL could be generated, even if we keep long-running transactionsaside. But I think still it will serve the purpose of what Satya is trying to achieve. >> >> >> I am afraid there are problems with making the RPO check post releasing the locks. By this time the transaction is committedand visible to the other backends (ProcArrayEndTransaction is already called) though the intention is to block committingtransactions that violate the defined RPO. Even though we block existing connections starting a new transaction,it is possible to do writes by opening a new connection / canceling the query. I am not too much worried aboutthe lock contention as the system is already hosed because of the policy. This behavior is very similar to what happenswhen the Sync standby is not responding. Thoughts? > > > Yeah, that's true, but even if we are blocking the transactions from committing then also it is possible that a new connectioncan come and generate more WAL, yeah but I agree with the other part that if you throttle after committing thenthe user can cancel the queries and generate more WAL from those sessions as well. But that is an extreme case whereapplication developers want to bypass the throttling and want to generate more WALs. How about having the new hook at the start of the new txn? If we do this, when the limit for the throttling is exceeded, the current txn (even if it is a long running one) continues to do the WAL insertions, the next txns would get blocked. Thoughts? Regards, Bharath Rupireddy.
В списке pgsql-hackers по дате отправления: