Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes
| От | SATYANARAYANA NARLAPURAM |
|---|---|
| Тема | Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes |
| Дата | |
| Msg-id | CAHg+QDcAuKTbNaNph+km2=6+KueG98iQQL3WibbnxqZ65uCmYw@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 Fri, Dec 24, 2021 at 3:13 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Fri, Dec 24, 2021 at 3:27 AM SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> wrote:XLogInsert in my opinion is the best place to call it and the hook can be something like this "void xlog_insert_hook(NULL)" as all the throttling logic required is the current flush position which can be obtained from GetFlushRecPtr and the ReplicationSlotCtl. Attached a draft patch.IMHO, it is not a good idea to call an external hook function inside a critical section. Generally, we ensure that we do not call any code path within a critical section which can throw an error and if we start calling the external hook then we lose that control.
Thank you for the comment. XLogInsertRecord is inside a critical section but not XLogInsert. Am I missing something?
It should be blocked at the operation level itself e.g. ALTER TABLE READ ONLY, or by some other hook at a little higher level.
There is a lot of maintenance overhead with a custom implementation at individual databases and tables level. This doesn't provide the necessary control that I am looking for.
В списке pgsql-hackers по дате отправления: