Lists: | pgsql-hackers |
---|
From: | Samuel Vogel <s(at)muel-vogel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Print b-tree tuples |
Date: | 2013-01-03 16:48:26 |
Message-ID: | 50E5B65A.70009@muel-vogel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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;
Any help with reviewing my my small attached patch would be greatly
appreciated!
Regards,
Samuel Vogel
Attachment | Content-Type | Size |
---|---|---|
print-btree-tuples.patch | text/plain | 2.1 KB |
From: | Samuel Vogel <s(at)muel-vogel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Print b-tree tuples |
Date: | 2013-01-04 12:00:21 |
Message-ID: | 50E6C455.90009@muel-vogel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Samuel Vogel <s(at)muel-vogel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Print b-tree tuples |
Date: | 2013-01-04 20:26:02 |
Message-ID: | 24713.1357331162@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Samuel Vogel <s(at)muel-vogel(dot)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
From: | Samuel Vogel <s(at)muel-vogel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Print b-tree tuples |
Date: | 2013-01-11 15:33:01 |
Message-ID: | 50F030AD.1080905@muel-vogel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Am 04.01.13 21:26, schrieb Tom Lane:
> Samuel Vogel <s(at)muel-vogel(dot)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