Request for error explaination || Adding a new integer in indextupleData Structure

Hi All,

I was trying to modify indextupledata structure by adding an integer
variable. ButI faced an error message "psql: FATAL: could not find tuple
for opclass 10032".

Could anyone please help me in resolving this issue.

Regards,
Rohit Goyal

--
Regards,
Rohit Goyal

Rohit Goyal <rhtgyl.87@gmail.com> writes:

Hi All,
I was trying to modify indextupledata structure by adding an integer
variable. ButI faced an error message "psql: FATAL: could not find tuple
for opclass 10032".

Could anyone please help me in resolving this issue.

You broke a system catalog index. Without seeing what you changed and
where, it's impossible to say just how, but that's the bottom line.

In recent versions of PG, opclass 10032 is btree name_ops (unless you've
also added/removed system catalog entries), which is a pretty plausible
thing to be one of the first indexscanned fetches during relcache.c
initialization, so I don't think there's any great significance in this
particular error message. It's likely that you broke *all* indexscans
not just one specific one.

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

Rohit Goyal <rhtgyl.87@gmail.com> writes:

Hi All,
I was trying to modify indextupledata structure by adding an integer
variable. ButI faced an error message "psql: FATAL: could not find

tuple

for opclass 10032".

Could anyone please help me in resolving this issue.

You broke a system catalog index. Without seeing what you changed and
where, it's impossible to say just how, but that's the bottom line.

This is the first line which i want to write in the code. Can you tel me

how to add an integer in indextupledata structure if I have a fresh system
with no changes?

In recent versions of PG, opclass 10032 is btree name_ops (unless you've

also added/removed system catalog entries), which is a pretty plausible
thing to be one of the first indexscanned fetches during relcache.c
initialization, so I don't think there's any great significance in this
particular error message. It's likely that you broke *all* indexscans
not just one specific one.

I am not sure how i can break all indexscan as this is the first line I
wrote in the code.

regards, tom lane

Hello,

I started all the process again and configured my eclipse with raw
postgresql code. First change i made in the code is

I added *int i; *in indextupleData structure in itup.h.

I got the same error message. Please help me to understand and solve the
issue. I want to add an integer in index tuple for btree.

Regards,
Rohit Goyal

On Tue, Jan 28, 2014 at 10:57 AM, Rohit Goyal <rhtgyl.87@gmail.com> wrote:

Hello,

I started all the process again and configured my eclipse with raw
postgresql code. First change i made in the code is

I added *int i; *in indextupleData structure in itup.h.

You should show us *exactly* where you added it. (Doing so is what "diff"
was developed for, so please use that or a similar tool.)

I got the same error message. Please help me to understand and solve the
issue. I want to add an integer in index tuple for btree.

The data from IndexTupleData is written to disk, and then read back in
again. Did you initdb a new database cluster after you made your change?
If you did the initdb with the original code, and then tried to point your
new code at the old disk files, that is very unlikely to work, as format is
now different.

Cheers,

Jeff

Hello,

I started all the process again and configured my eclipse with raw
postgresql code. First change i made in the code is

I added *int i; *in indextupleData structure in itup.h.

You should show us *exactly* where you added it. (Doing so is what "diff"
was developed for, so please use that or a similar tool.)

I got the same error message. Please help me to understand and solve the
issue. I want to add an integer in index tuple for btree.

The data from IndexTupleData is written to disk, and then read back in
again. Did you initdb a new database cluster after you made your change?
If you did the initdb with the original code, and then tried to point your
new code at the old disk files, that is very unlikely to work, as format is
now different.

Cheers,

Jeff

Hi Jeff and Tom,

Thanks you so much. I was making the mistake you mentioned in the last
mail. :)

Regards,
Rohit Goyal

--
Regards,
Rohit Goyal

On 1/28/14, 3:59 PM, Rohit Goyal wrote:

The data from IndexTupleData is written to disk, and then read back in again. Did you initdb a new database cluster after you made your change? If you did the initdb with the original code, and then tried to point your new code at the old disk files, that is very unlikely to work, as format is now different.

Cheers,

Jeff

Hi Jeff and Tom,

Thanks you so much. I was making the mistake you mentioned in the last mail. :)

The real issue here is that you need to bump the catalog version number (sorry, but I don't know where that is in code).
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net

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