Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>

To: Peter Geoghegan <pg@bowt.ie>

Cc: Bowen Shi <zxwsbg12138@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Noah Misch <noah@leadboat.com>, Alexander Lakhin <exclusion@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>

Date: 2024-05-16T19:39:53Z

Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Ensure vacuum removes all visibly dead tuples older than OldestXmin
- 06bf404cd07b 16.4 landed
- 45ce054c02b8 14.13 landed
- dc6354c67017 15.8 landed
Combine freezing and pruning steps in VACUUM
- 6dbb490261a6 17.0 cited
Handle non-chain tuples outside of heap_prune_chain()
- 6f47f6883151 17.0 cited
Fix false reports in pg_visibility
- e85662df44ff 17.0 cited
Remove retry loop in heap_page_prune().
- 1ccc1e05ae8f 17.0 cited
vacuumlazy.c: document vistest and OldestXmin.
- 73f6ec3d3c8d 15.0 cited
Deduplicate choice of horizon for a relation procarray.c.
- d9d8aa9bb9aa 15.0 cited
Remove tupgone special case from vacuumlazy.c.
- 8523492d4e34 14.0 cited
Simplify state managed by VACUUM.
- b4af70cb2103 14.0 cited
Recycle nbtree pages deleted during same VACUUM.
- 9dd963ae2534 14.0 cited
snapshot scalability: Don't compute global horizons while building snapshots.
- dc7420c2c927 14.0 cited
Raise error when affecting tuple moved into different partition.
- f16241bef7cc 11.0 cited

Hi,

On 2024-05-16 12:49:00 -0400, Peter Geoghegan wrote:
> On Thu, May 16, 2024 at 12:38 PM Andres Freund <andres@anarazel.de> wrote:
> > I'm wondering if there was index processing, due to the number of tuples. And
> > if so, what type of indexes. There'd need to be something that could lead to
> > new snapshots being acquired...
> 
> Did you ever see this theory of mine, about B-Tree page deletion +
> recycling? See:
> 
> https://www.postgresql.org/message-id/flat/CAH2-Wz%3DzLcnZO8MqPXQLqOLY%3DCAwQhdvs5Ncg6qMb5nMAam0EA%40mail.gmail.com#d058a6d4b8c8fa7d1ff14349b3a50c3c
> 
> (And related nearby emails from me.)

> It looked very much like index vacuuming was involved in some way when
> I actually had the opportunity to use gdb against an affected
> production instance that ran into the problem.

Hm, were the cases you observed that way using parallel vacuuming? And what
index types were involved?

Melanies reproducer works because there are catalog accesses that can trigger
a recomputation of fuzzy horizon. For testing the "easy" window for that is
the vac_open_indexes() < 16, because it happens after determining the horizon,
but before actually vacuuming.

Now I wonder if there is some codepath triggering catalog lookups during bulk
delete.

Greetings,

Andres Freund