Horton

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

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Teodor Sigaev <teodor@sigaev.ru>, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2020-05-02T21:12:44Z
Lists: 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

Commits

  1. Refactor btvacuumpage().

  2. Fix undercounting in VACUUM VERBOSE output.

  3. Fix bug in nbtree VACUUM "skip full scan" feature.

  4. Skip full index scan during cleanup of B-tree indexes when possible