| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune() |
| Date: | 2024-04-26 21:28:06 |
| Message-ID: | CAH2-Wz=_FWEs2YSa=ggKuXhZtdCPiORKhk2JWu1bcVNb+hJdxw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Apr 26, 2024 at 4:46 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> I have a more basic question. How could GlobalVisState->maybe_needed
> going backwards cause a problem with relfrozenxid? Yes, if
> maybe_needed goes backwards, we may not remove a tuple whose xmin/xmax
> are older than VacuumCutoffs->OldestXmin. But, if that tuple's
> xmin/xmax are older than OldestXmin, then wouldn't we freeze it?
You can't freeze every XID older than OldestXmin.
heap_prepare_freeze_tuple() isn't prepared for HEAPTUPLE_DEAD tuples,
and expects that those will be taken care of by the time it is called.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2024-04-26 21:56:36 | Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune() |
| Previous Message | Melanie Plageman | 2024-04-26 20:46:46 | Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune() |