Print b-tree tuples

Hello,

I'm trying to print out the tuples in the b-tree nodes for analysis,
but when iterate over more than the first entry of the tuples
(scanKey++), I strangely get the error below on query execution:
ERROR: relation "simpletest" does not exist
LINE 1: SELECT * FROM simpletest WHERE id = 50;

I was able to get around this by only printing byval attributes:

if (!itupdesc->attrs[i-1]->attbyval)
break;

I would still like to know why my code screws up though. The relnames
are not byval, but I should still be able to print the address, right?

Regards,
Samuel

Samuel Vogel <s@muel-vogel.de> writes:

I'm trying to print out the tuples in the b-tree nodes for analysis, but
when iterate over more than the first entry of the tuples (scanKey++), I
strangely get the error below on query execution:
ERROR: relation "simpletest" does not exist
LINE 1: SELECT * FROM simpletest WHERE id = 50;

Is this patch the only thing you changed? The only obvious explanation
for the above error (other than "you fat-fingered the query") seems to
be that you caused index searches in pg_class to fail, but I don't see
how this patch could be affecting the result of _bt_binsrch.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Am 04.01.13 21:26, schrieb Tom Lane:

Samuel Vogel <s@muel-vogel.de> writes:

I'm trying to print out the tuples in the b-tree nodes for analysis, but
when iterate over more than the first entry of the tuples (scanKey++), I
strangely get the error below on query execution:
ERROR: relation "simpletest" does not exist
LINE 1: SELECT * FROM simpletest WHERE id = 50;

Is this patch the only thing you changed? The only obvious explanation
for the above error (other than "you fat-fingered the query") seems to
be that you caused index searches in pg_class to fail, but I don't see
how this patch could be affecting the result of _bt_binsrch.

Yes, I've switched to a clean master and only applied this patch. If I
put the the break, the query works, so it's fine as well.

BTW: I just had a discussion if it would make sense, to recreate my test
table with a different order, as a b-tree is always dependent on
insertion order. But as the b-tree index is newly created in memory
after each restart, two different insertion orders (same values) would
give me the same b-tree at least after a restart, right?

Regards,
Samuel

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers