Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin

On Tue, Jun 25, 2024 at 11:39 AM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> On Tue, Jun 25, 2024 at 10:31 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Tue, Jun 25, 2024 at 9:07 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > It's not hard - but it has downsides. It'll mean that - outside of vacuum -
> > > we'll much more often not react to horizons going backwards due to
> > > hot_standby_feedback. Which means that hot_standby_feedback, when used without
> > > slots, will prevent fewer conflicts.
> >
> > Can you explain this in more detail?
>
> If we prevent GlobalVisState from moving backward, then we would less
> frequently be pushing the horizon backward on the primary in response
> to hot standby feedback. Then, the primary would do more things that
> would not be safely replayable on the standby -- so the standby could
> end up encountering more recovery conflicts.

I don't get it. hot_standby_feedback only moves horizons backward on
the primary, AFAIK, when it first connects, or when it reconnects.
Which I guess could be frequent for some users with flaky networks,
but does that really rise to the level of "much more often"?

--
Robert Haas
EDB: http://www.enterprisedb.com