Re: WIP: Covering + unique indexes. - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: WIP: Covering + unique indexes.
Date
Msg-id CAH2-Wz=3pjEmDDW+RcPEXAR16aDMOOrVKEWvQBhpb8nPfgf2qg@mail.gmail.com
Whole thread Raw
In response to Re: WIP: Covering + unique indexes.  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Fri, Mar 30, 2018 at 10:39 PM, Peter Geoghegan <pg@bowt.ie> wrote:
> It's safe, although I admit that that's a bit hard to see.
> Specifically, look at this code in _bt_insert_parent():
>
>         /*
>          * Find the parent buffer and get the parent page.
>          *
>          * Oops - if we were moved right then we need to change stack item! We
>          * want to find parent pointing to where we are, right ?    - vadim
>          * 05/27/97
>          */
>         ItemPointerSet(&(stack->bts_btentry.t_tid), bknum, P_HIKEY);
>         pbuf = _bt_getstackbuf(rel, stack, BT_WRITE);
>
> Vadim doesn't seem too sure of why he did it that way. What's clear is
> that the offset on all internal pages is always P_HIKEY (that is, 1),
> because this is the one and only place where new IndexTuples get
> generated for internal pages. That's unambiguous. So how could
> BTEntrySame() truly need to care about offset? How could there ever be
> an internal page offset that wasn't just P_HIKEY? You can look
> yourself, using pg_hexedit or pageinspect.

Sorry, I meant this code, right before:

        /* form an index tuple that points at the new right page */
        new_item = CopyIndexTuple(ritem);
        ItemPointerSet(&(new_item->t_tid), rbknum, P_HIKEY);

-- 
Peter Geoghegan


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: WIP: Covering + unique indexes.
Next
From: CharSyam
Date:
Subject: Re: [HACKERS][PATCH] adding simple sock check for windows