Skip site navigation (1) Skip section navigation (2)

PageGetMaxOffsetNumber

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: PageGetMaxOffsetNumber
Date: 2002-12-16 02:49:57
Message-ID: 20021216024957.GA30167@dcc.uchile.cl (view raw or flat)
Thread:
Lists: pgsql-hackers
Hello hackers,

I wonder what the PageGetMaxOffsetNumber macro is supposed to do (in a
btree index page)?

The scenario is the following:  I need to get the pointer to a btree
page (leaf or internal) in its parent page, to call _bt_itemdel on it.
The only thing I can think of is to use its parent link and then iterate
in every OffsetNumber to see which item points down to the page I'm
looking for.  I think the gotcha here is that the parent page can split
and I may have to walk right in order to find the new parent (Is this
right?  Can the parent go someplace else?)

I iterate over the elements of the parent page in a for loop, and the
upper bound is rarely reached because the item is found.  However
sometimes the item isn't found, and PageGetItem fails its assertion
because the item isn't used (LP_USED).  I have found that
PageGetMaxOffsetNumber (the upper bound) returns a consistent value
that's far too high (4294967291, 0xFFFFFFFB) and therefore the for loop
eventually falls out of bounds.


The btree freelist patch is "almost ready" (which means it works in the
trivial cases I've tested and there are some corner cases I haven't
even covered), however I am stuck on this.  Can anyone give me a light?
Maybe there's another way to get at the pointer to a page in its parent?

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Crear es tan dificil como ser libre" (Elsa Triolet)

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2002-12-16 03:05:20
Subject: Re: PageGetMaxOffsetNumber
Previous:From: Christopher Kings-LynneDate: 2002-12-16 02:23:27
Subject: Re: [GENERAL] PostgreSQL Global Development Group

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group