Re: Corrupted btree index on HEAD because of covering indexes

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Corrupted btree index on HEAD because of covering indexes
Дата
Msg-id CAH2-Wz=kzqtGPEnv7q4P8afP3EtEdU94wgZsMc2DJ6xKWy06Kw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Corrupted btree index on HEAD because of covering indexes  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Is there a memory leak in commit 8561e48?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Problem while setting the fpw with SIGHUP