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

From Teodor Sigaev
Subject Re: Corrupted btree index on HEAD because of covering indexes
Date
Msg-id 24ac23bf-bf00-229c-8ef3-f60542cab627@sigaev.ru
Whole thread Raw
In response to Re: Corrupted btree index on HEAD because of covering indexes  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: Corrupted btree index on HEAD because of covering indexes  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
>> Should we use BTreeInnerTupleGetDownLink() as soon as we use
>> BTreeInnerTupleSetDownLink() for setting this?
>> Or even invent BTreeInnerTupleDownLinkIsValid() macro?
> I am not sure. Here we actually store UP link - to top parent to remove. I'm 
> afraid using BTreeInnerTupleGetDownLink/BTreeInnerTupleSetDownLink could cause a 
> confusion, in other hand, introducing 
> TreeInnerTupleGetUpLink/BTreeInnerTupleSetUpLink seems over-engineering
> 

After close look I change my opinion. To have a clean code it's much better to 
have new pair get/set macroses specialy to manage link to top pare during page 
deletion. This removes last naked usage of 
ItemPointer(SetInvalid/IsInvalid/GetBlockNumberNoCheck) and uses self-described 
macroses. Patch is attached.


-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: SHOW ALL does not honor pg_read_all_settings membership
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] proposal: schema variables