Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
От | Robert Haas |
---|---|
Тема | Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin |
Дата | |
Msg-id | CA+TgmoYvmgTDqYsrJZ8_SvF_cBNy0Q7gDwo2YQ6ohULCoUmzrw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin (Melanie Plageman <melanieplageman@gmail.com>) |
Ответы |
Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
|
Список | pgsql-hackers |
On Tue, Jun 25, 2024 at 11:39 AM Melanie Plageman <melanieplageman@gmail.com> wrote: > On Tue, Jun 25, 2024 at 10:31 AM Robert Haas <robertmhaas@gmail.com> wrote: > > On Tue, Jun 25, 2024 at 9:07 AM Andres Freund <andres@anarazel.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
В списке pgsql-hackers по дате отправления: