Horton

Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae

Bowen Shi <zxwsbg12138@gmail.com>

View thread
From: Bowen Shi <zxwsbg12138@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Andres Freund <andres@anarazel.de>, 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-28T06:31:54Z
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 →

  1. Ensure vacuum removes all visibly dead tuples older than OldestXmin

  2. Combine freezing and pruning steps in VACUUM

  3. Handle non-chain tuples outside of heap_prune_chain()

  4. Fix false reports in pg_visibility

  5. Remove retry loop in heap_page_prune().

  6. vacuumlazy.c: document vistest and OldestXmin.

  7. Deduplicate choice of horizon for a relation procarray.c.

  8. Remove tupgone special case from vacuumlazy.c.

  9. Simplify state managed by VACUUM.

  10. Recycle nbtree pages deleted during same VACUUM.

  11. snapshot scalability: Don't compute global horizons while building snapshots.

  12. Raise error when affecting tuple moved into different partition.

Hi,

On Fri, May 17, 2024 at 12:29 PM Peter Geoghegan <pg@bowt.ie> wrote:

> On Thu, May 16, 2024 at 11:36 PM Bowen Shi <zxwsbg12138@gmail.com> wrote:
> > From the current situation, I feel that the scenario I encountered is
> different from yours because it doesn't seem to be the first page of the
> vacuum scanning.
>
> Really? I think it looks like the same issue.
>
> What I saw was that the heap page that lazy_scan_prune locked up on
> was the first page scanned *after* the first round of index vacuuming
> -- *not* the first heap page scanned overall.
>
> I misunderstood earlier.


> I also saw "num_index_scans == 1", "tuples_deleted == lpdead_items",
> and "scanned_pages == lpdead_item_pages" when I looked at the locked
> up Postgres 15 production instance (or close to it). I can't tell if
> your dead_items is shown as empty, too, but if it is then that
> indicates that the heap page that your lazy_scan_prune trace relates
> to is the first page scanned after a round of index vacuuming (the
> first round).
>
> If you can show more about dead_items, then it will either confirm or
> disprove my theory about it being the same issue.
>

(gdb) p *vacrel->dead_items
$2 = {max_items = 11184809, num_items = 0, items = 0x7fa22f48d048}
(gdb) p *vacrel->dead_items->items
$3 = {ip_blkid = {bi_hi = 0, bi_lo = 0}, ip_posid = 1}

The num_items is zero.


-- 
Regards
Bowen Shi