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+Tgmob4m4TjFCqKFvdR9=Y71fGoH_C-nfPgni6Trt8t3AKOLA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin |
Список | pgsql-hackers |
On Mon, Jun 24, 2024 at 12:43 PM Peter Geoghegan <pg@bowt.ie> wrote: > The problem here is that OldestXmin is supposed to be more > conservative than vistest, which it almost always is, except in this > one edge case. I don't think that plugging that hole changes the basic > fact that there is one source of truth about what *needs* to be > pruned. There is such a source of truth: OldestXmin. Well, another approach could be to make it so that OldestXmin actually is always more conservative than vistest rather than almost always. I agree with you that letting the pruning horizon move forward during vacuum is desirable. I'm just wondering if having the vacuum code need to know a second horizon is really the best way to address that. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: