Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
От | Alvaro Herrera |
---|---|
Тема | Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic |
Дата | |
Msg-id | 202106101814.3esill6k2a4o@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic (Peter Geoghegan <pg@bowt.ie>) |
Список | pgsql-hackers |
On 2021-Jun-10, Peter Geoghegan wrote: > On Thu, Jun 10, 2021 at 10:29 AM Matthias van de Meent > <boekewurm+postgres@gmail.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)
В списке pgsql-hackers по дате отправления: