| From: | Torsten Förtsch <tfoertsch123(at)gmail(dot)com> |
|---|---|
| To: | sud <suds1434(at)gmail(dot)com> |
| Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Long running query causing XID limit breach |
| Date: | 2024-05-26 19:25:26 |
| Message-ID: | CAKkG4_nAivibkJigR1Pwtd5J7SkCWWMjivPbMLSgykKJa1AM0Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Sun, May 26, 2024 at 8:46 PM sud <suds1434(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | sud | 2024-05-27 03:37:00 | Re: Long running query causing XID limit breach |
| Previous Message | sud | 2024-05-26 18:46:40 | Re: Long running query causing XID limit breach |