Re: Fixes for two separate bugs in nbtree VACUUM's page deletion - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Fixes for two separate bugs in nbtree VACUUM's page deletion
Date
Msg-id CAH2-WzmebF46KN0GEs6RtNzoK_SBRhLMF0A++y_Z5XsS6Y_btA@mail.gmail.com
Whole thread Raw
In response to Re: Fixes for two separate bugs in nbtree VACUUM's page deletion  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
List pgsql-hackers
On Thu, Apr 30, 2020 at 12:20 AM Masahiko Sawada
<masahiko.sawada@2ndquadrant.com> wrote:
> For the part of treating that case as an index corruption I will need
> some time to review because of lacking knowledge of btree indexes. So
> I'll review it later.

I pushed the refactoring patch today. Thanks for the review.

The final test for corruption that I added to btvacuumscan() is less
aggressive than what you saw in the patch I posted. We only report
corruption when backtracking/recursing if the page is "new", not a
leaf page, or is half-dead. We don't treat a fully deleted page as
corruption, because there is a case where the same call to
btvacuumscan() may have called _bt_pagedel() already, which may have
deleted the block that we backtrack/recurse to. The "sibling links
cannot point to a deleted page without concurrent deletion, and we
know that can't happen because we are VACUUM" stuff doesn't really
apply -- we remember which block we will recurse to *before* we
actually call _bt_pagedel().

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Problems with GSS encryption and SSL in libpq in 12~
Next
From: Noah Misch
Date:
Subject: Re: Failed test 'pg_recvlogical acknowledged changes, nothingpending on slot'