| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic |
| Date: | 2021-06-08 17:17:11 |
| Message-ID: | 20210608171711.oyvhqqsvtkja33os@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2021-06-08 14:27:14 +0200, Matthias van de Meent wrote:
> heap_prune_satisfies_vacuum considers 1 more transaction to be
> unvacuumable, and thus indeed won't vacuum that tuple that
> HeapTupleSatisfiesVacuum does want to be vacuumed.
>
> The new open question is now: Why is
> GlobalVisCatalogRels->maybe_needed < OldestXmin? IIRC
> GLobalVisCatalogRels->maybe_needed is constructed from the same
> ComputeXidHorizonsResult->catalog_oldest_nonremovable which later is
> returned to be used in vacrel->OldestXmin.
The horizon used by pruning is only updated once per transaction (well,
approximately). What presumably is happening is that the retry loop is
retrying, without updating the horizon, therefore the same thing is
happening over and over again?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2021-06-08 17:34:04 | Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic |
| Previous Message | Tom Lane | 2021-06-08 16:52:16 | Re: Make unlogged table resets detectable |