Re: Corrupted btree index on HEAD because of covering indexes - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Corrupted btree index on HEAD because of covering indexes
Date
Msg-id CAH2-Wz=kzqtGPEnv7q4P8afP3EtEdU94wgZsMc2DJ6xKWy06Kw@mail.gmail.com
Whole thread Raw
In response to Re: Corrupted btree index on HEAD because of covering indexes  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List pgsql-hackers
On Thu, Apr 19, 2018 at 2:00 PM, Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> - if (ItemPointerIsValid(leafhikey))
> + if (ItemPointerGetBlockNumberNoCheck(leafhikey) != InvalidBlockNumber)
>
> Should we use BTreeInnerTupleGetDownLink() as soon as we use
> BTreeInnerTupleSetDownLink() for setting this?
> Or even invent BTreeInnerTupleDownLinkIsValid() macro?

+1 to at least using BTreeInnerTupleGetDownLink().

I think it's okay to use ItemPointerGetBlockNumberNoCheck() in
amcheck, because it's inconvenient for amcheck to know if it's on the
leaf level or not (it's rather low-context code). However, the nbtree
code doesn't have that problem, and already has very few places that
could possibly need ItemPointerGetBlockNumberNoCheck(). In fact,
Teodor's fix touches the only remaining
ItemPointerGetBlockNumberNoCheck() caller code within all of nbtree.

In summary, I think that we should find a way to never use
ItemPointerGetBlockNumberNoCheck() in nbtree, while still using it in
amcheck.

-- 
Peter Geoghegan


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Is there a memory leak in commit 8561e48?
Next
From: Michael Paquier
Date:
Subject: Re: Problem while setting the fpw with SIGHUP