Re: [HACKERS] Cleanup: avoid direct use of ip_posid/ip_blkid - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: [HACKERS] Cleanup: avoid direct use of ip_posid/ip_blkid
Date
Msg-id CAH2-WznavEycofESzROEVutmhi=4aRfubwU29F+_k1RQnotXqg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Cleanup: avoid direct use of ip_posid/ip_blkid  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On Thu, Mar 2, 2017 at 8:25 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> I wonder why we allow that.  Shouldn't the tid type reject input that
> has ip_posid == 0?

InvalidOffsetNumber (that is, 0) is something that I wouldn't like to
bet doesn't make it out to disk at some point. I know that we use 1 as
a meaningless placeholder value for internal B-Tree pages. P_HIKEY is
where I get 1 from, which might as well be any other value in
practice, I think -- we only need an item pointer to point to a block
from an internal page. SpecTokenOffsetNumber can certainly make it to
disk, and that is invalid in some sense, even if it isn't actually set
to InvalidOffsetNumber. So, seems pretty risky to me.


-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: [HACKERS] delta relations in AFTER triggers
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] brin autosummarization -- autovacuum "work items"