Re: Improve search for missing parent downlinks in amcheck

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improve search for missing parent downlinks in amcheck
Date: 2020-01-24 01:40:37
Message-ID: CAH2-WzmqizDnmHifdbp7rs39ZWnqKhcHjOKCu8YrNJqLazFaZA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 23, 2020 at 5:31 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> In summary: I suppose that we can also solve "the cousin problem"
> quite easily, but only for rightmost cousins within a subtree --
> leftmost cousins might be too messy to verify for it to be worth it.
> We don't want to have to jump two or three levels up within
> bt_downlink_connectivity_check() just for leftmost cousin pages. But
> maybe you're feeling ambitious! What do you think?

I suppose the alternative is to get the high key of the parent's left
sibling, rather than going to the parent's parent (i.e. our
grandparent). That would probably be the best way to get a separator
key to compare against the high key in the leftmost cousin page of a
subtree, if in fact we wanted to *fully* solve the "cousin problem".
Goetz Graefe recommends keeping both a low key and a high key in every
page for verification purposes. We don't actually have a low key (we
only have a truncated negative infinity item), but this approach isn't
that far off having a low key.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2020-01-24 02:27:49 Re: Improve search for missing parent downlinks in amcheck
Previous Message Peter Geoghegan 2020-01-24 01:31:18 Re: Improve search for missing parent downlinks in amcheck