| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, 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-10 18:14:55 |
| Message-ID: | 202106101814.3esill6k2a4o@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2021-Jun-10, Peter Geoghegan wrote:
> On Thu, Jun 10, 2021 at 10:29 AM Matthias van de Meent
> <boekewurm+postgres(at)gmail(dot)com> wrote:
> > I see one exit for HEAPTUPLE_DEAD on a potentially recently committed
> > xvac (?), and we might also check against recently committed
> > transactions if xmin == xmax, although apparently that is not
> > implemented right now.
xvac was used by the pre-9.0 VACUUM FULL, so I don't think it's possible
to see a recently committed one. (I think you'd have to find a table
that was pg_upgraded from 8.4 or older, with leftover tuples from an
aborted VACUUM FULL, and never vacuumed after that.)
A scenario with such a tuple on disk is not impossible [in theory],
but if it does exist, then the VACUUM FULL would not be in the
possibly-visible horizon.
--
Álvaro Herrera Valdivia, Chile
"Linux transformó mi computadora, de una `máquina para hacer cosas',
en un aparato realmente entretenido, sobre el cual cada día aprendo
algo nuevo" (Jaime Salinas)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2021-06-10 18:23:39 | Re: AWS forcing PG upgrade from v9.6 a disaster |
| Previous Message | Tom Lane | 2021-06-10 18:00:17 | Re: AWS forcing PG upgrade from v9.6 a disaster |