Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
От | Peter Geoghegan |
---|---|
Тема | Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin |
Дата | |
Msg-id | CAH2-Wzn7EqLndKP4pVtxd8QHvTa_Ev_gU=tELz-aaC3Q0yGuTA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
|
Список | pgsql-hackers |
On Mon, Jun 24, 2024 at 9:30 PM Noah Misch <noah@leadboat.com> wrote: > On Mon, Jun 24, 2024 at 03:23:39PM -0400, Melanie Plageman wrote: > > Right now, in master, we do use a single horizon when determining what > > is pruned -- that from GlobalVisState. OldestXmin is only used for > > freezing and full page visibility determinations. Using a different > > horizon for pruning by vacuum than freezing is what is causing the > > error on master. > > Agreed, and I think using different sources for pruning and freezing is a > recipe for future bugs. Fundamentally, both are about answering "is > snapshot_considers_xid_in_progress(snapshot, xid) false for every snapshot?" > That's not to say this thread shall unify the two, but I suspect that's the > right long-term direction. What does it really mean to unify the two, though? If the OldestXmin field was located in struct GlobalVisState (next to definitely_needed and maybe_needed), but everything worked in essentially the same way as it will with Melanie's patch in place, would that count as unifying the two? Why or why not? -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: