On Sat, Mar 16, 2019 at 2:01 PM Peter Geoghegan <p...@bowt.ie> wrote: > > On Sat, Mar 16, 2019 at 1:47 PM Peter Geoghegan <p...@bowt.ie> wrote: > > I agree that it's always true that the high key is also in the parent, > > and we could cross-check that within the child. Actually, I should > > probably figure out a way of arranging for the Bloom filter used > > within bt_relocate_from_root() (which has been around since PG v11) to > > include the key itself when fingerprinting. That would probably > > necessitate that we don't truncate "negative infinity" items (it was > > actually that way about 18 years ago), just for the benefit of > > verification. > > Clarification: You'd fingerprint an entire pivot tuple -- key, block > number, everything. Then, you'd probe the Bloom filter for the high > key one level down, with the downlink block in the high key set to > point to the current sibling on the same level (the child level). As I > said, I think that the only reason that that cannot be done at present > is because of the micro-optimization of truncating the first item on > the right page to zero attributes during an internal page split. (We > can retain the key without getting rid of the hard-coded logic for > negative infinity within _bt_compare()). > > bt_relocate_from_root() already has smarts around interrupted page > splits (with the incomplete split bit set).
Clarification to my clarification: I meant bt_downlink_missing_check(), not bt_relocate_from_root(). The former really has been around since v11, unlike the latter, which is part of this new amcheck patch we're discussing. -- Peter Geoghegan
