From: | sirisha chamarthi <sirichamarthi22(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Vik Fearing <vik(at)postgresfriends(dot)org>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Why is hot_standby_feedback off by default? |
Date: | 2023-10-23 01:26:23 |
Message-ID: | CAKrAKeXfsJOsjLSPZfoWPOuN9vf+y0s2eKi1QQLQfoWaASFaWg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Andres,
On Sun, Oct 22, 2023 at 12:08 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> Hi,
>
> On October 22, 2023 4:56:15 AM PDT, Vik Fearing <vik(at)postgresfriends(dot)org>
> wrote:
> >On 10/22/23 09:50, sirisha chamarthi wrote:
> >> Is there any specific reason hot_standby_feedback default is set to off?
> >
> >
> >Yes. No one wants a rogue standby to ruin production.
>
> Medium term, I think we need an approximate xid->"time of assignment"
> mapping that's continually maintained on the primary. One of the things
> that'd show us to do is introduce a GUC to control the maximum effect of
> hs_feedback on the primary, in a useful unit. Numbers of xids are not a
> useful unit (100k xids is forever on some systems, a few minutes at best on
> others, the rate is not necessarily that steady when plpgsql exception
> handles are used, ...)
>
+1 on this idea. Please let me give this a try.
Thanks,
Sirisha
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-10-23 01:47:50 | Re: pgstatindex vs. !indisready |
Previous Message | Michael Paquier | 2023-10-23 01:24:30 | Re: Remove extraneous break condition in logical slot advance function |