Re: Long running query causing XID limit breach
От | Torsten Förtsch |
---|---|
Тема | Re: Long running query causing XID limit breach |
Дата | |
Msg-id | CAKkG4_nAivibkJigR1Pwtd5J7SkCWWMjivPbMLSgykKJa1AM0Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Long running query causing XID limit breach (sud <suds1434@gmail.com>) |
Ответы |
Re: Long running query causing XID limit breach
|
Список | pgsql-general |
On Sun, May 26, 2024 at 8:46 PM sud <suds1434@gmail.com> wrote:
Would you agree that we should have two standby, one with default max_standby_streaming_delay (say 10 sec ) which will be mainly used as high availability and thus will be having minimal lag. and another standby with max_standby_streaming_delay as "-1" i.e. it will wait indefinitely for the SELECT queries to finish without caring about the lag, which will be utilized for the long running SELECT queries.And keep the hot_standby_feedback as ON for the first standby which is used as HA/high availability. And keep the hot_standby_feedback as OFF for the second standby which is utilized for long running SELECT queries, so that primary won't be waiting for the response/feedback from this standby to vacuum its old transactions and that will keep the transaction id wrap around issue from not happening because of the Read/Select queries on any of the standby.
Sure. That could work. Perhaps also set statement_timeout on the first replica, just in case.
В списке pgsql-general по дате отправления: