Re: Fixes for two separate bugs in nbtree VACUUM's page deletion

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: Fixes for two separate bugs in nbtree VACUUM's page deletion
Date: 2020-05-02 21:12:44
Message-ID: CAH2-WzmebF46KN0GEs6RtNzoK_SBRhLMF0A++y_Z5XsS6Y_btA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 30, 2020 at 12:20 AM Masahiko Sawada
<masahiko(dot)sawada(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2020-05-02 22:16:47 Re: Failed test 'pg_recvlogical acknowledged changes, nothing pending on slot'
Previous Message Stephen Frost 2020-05-02 18:26:50 Re: Problems with GSS encryption and SSL in libpq in 12~