From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
Subject: | Re: amcheck (B-Tree integrity checking tool) |
Date: | 2016-03-15 07:11:01 |
Message-ID: | CAM3SWZRyovWOMkpP3SMyNBAi8ksfW61VqjpJDyhw8Mi66xhXHw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 14, 2016 at 11:48 PM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> Dunno about that. It's defining characteristic is that it checks child
>> pages against their parent IMV. Things are not often defined in terms
>> of their locking requirements.
>
> At the risk of sounding a bit verbose, do bt_check_level() for a check
> that inspects a level at a time and bt_check_multi_level() for a check
> that spans levels sound descriptive?
Hmm. But all functions verify multiple levels. What distinguishes
bt_index_parent_check()'s verification is that the downlinks in
internal pages are checked against actual child pages (every item in
the child page, in fact). It's the parent/child relationship that is
verified in addition to the standard checks of every page on and
across (not between) every level.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2016-03-15 07:13:17 | Re: propose: detail binding error log |
Previous Message | Ioseph Kim | 2016-03-15 07:06:19 | Re: propose: detail binding error log |