Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae - Mailing list pgsql-bugs

From Peter Geoghegan
Subject Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
Date
Msg-id CAH2-Wzk8BgAwKGOttaimEwSHXVC7+L1Wg6uEYb9Nuv6RJbemZQ@mail.gmail.com
Whole thread Raw
In response to Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae  (Bowen Shi <zxwsbg12138@gmail.com>)
Responses Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
List pgsql-bugs
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
bethe 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 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.

--
Peter Geoghegan



pgsql-bugs by date:

Previous
From: Bowen Shi
Date:
Subject: Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
Next
From: Retno Utami
Date:
Subject: Issues in finding libeay.dll and ssleay.dll for win x64