From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Cc: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: WIP: Covering + unique indexes. |
Date: | 2018-03-31 05:46:10 |
Message-ID: | CAH2-Wz=3pjEmDDW+RcPEXAR16aDMOOrVKEWvQBhpb8nPfgf2qg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 30, 2018 at 10:39 PM, Peter Geoghegan <pg(at)bowt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | CharSyam | 2018-03-31 06:12:46 | Re: [HACKERS][PATCH] adding simple sock check for windows |
Previous Message | Peter Geoghegan | 2018-03-31 05:39:40 | Re: WIP: Covering + unique indexes. |