Re: pg_amcheck contrib application - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: pg_amcheck contrib application
Date
Msg-id CAH2-WzmdypcxU6LdJ_QMf0KHNpaWJK4AJKLf-YjEuCtrEvGWwA@mail.gmail.com
Whole thread Raw
In response to Re: pg_amcheck contrib application  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_amcheck contrib application
List pgsql-hackers
On Tue, Mar 23, 2021 at 12:44 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I will make this change to HEAD soon, barring objections.
>
> +1.  Not deleting the upper page seems better than the alternatives.

FWIW it might also work that way as a holdover from the old page
deletion algorithm. These days we decide exactly which pages (leaf
page plus possible internal pages) are to be deleted as a whole up
front (these are a subtree, though usually just a degenerate
single-leaf-page subtree -- internal page deletions are rare).

One of the advantages of this design is that we verify practically all
of the work involved in deleting an entire subtree up-front, inside
_bt_lock_subtree_parent(). It's clearly safe to back out of it if it
looks dicey.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Jim Finnerty
Date:
Subject: Re: insensitive collations
Next
From: Fujii Masao
Date:
Subject: Re: Nicer error when connecting to standby with hot_standby=off