f



failed to re-find parent key

I have hacked analyze.c to automatically create a unique index on the
oid when a table is created and I am getting the failed to re-find
parent key in pg_attribute_relid_attnam_index every 8 attempts to do the
following

select * from foo into temp a;
drop table a;

Currently analyze does not create the oid index on the select into. 

I realize this is beyond the realm of supported code, but can anyone
tell me what's going on or a better way to fix it.

BTW, the real problem is that select * from foo where oid=? doesn't use
an index scan.

Dave
-- 
Dave Cramer
519 939 0336
ICQ # 1467551


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faqs/FAQ.html

0
pg
1/13/2004 9:30:48 PM
comp.postgresql.hackers 2733 articles. 0 followers. Post Follow

9 Replies
358 Views

Similar Articles

[PageSpeed] 3

Sorry folks, this is a red-herring, my hack didn't have anything to do
with it.  It occurs with or without the index. Question is was there a
bug between 7.4 and 7.4.1 which may have caused this?

Dave
On Tue, 2004-01-13 at 16:30, Dave Cramer wrote:
> I have hacked analyze.c to automatically create a unique index on the
> oid when a table is created and I am getting the failed to re-find
> parent key in pg_attribute_relid_attnam_index every 8 attempts to do the
> following
> 
> select * from foo into temp a;
> drop table a;
> 
> Currently analyze does not create the oid index on the select into. 
> 
> I realize this is beyond the realm of supported code, but can anyone
> tell me what's going on or a better way to fix it.
> 
> BTW, the real problem is that select * from foo where oid=? doesn't use
> an index scan.
> 
> Dave
-- 
Dave Cramer
519 939 0336
ICQ # 1467551


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

0
pg
1/13/2004 11:21:48 PM
Dave Cramer <pg@fastcrypt.com> writes:
> Sorry folks, this is a red-herring, my hack didn't have anything to do
> with it.

In that case you could provide a self-contained example?  I tried this
a few times in the regression database:

select * into temp a from tenk1; drop table a;

and saw no problem in either CVS tip or 7.4.*.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to majordomo@postgresql.org so that your
      message can get through to the mailing list cleanly

0
tgl
1/14/2004 12:05:31 AM
I can't recreate it either, it is only happening on my customers
machines, which are using an older version of redhat (7.2) and gcc 2.96

Is it possible these versions are relevant to the issue?

Dave

On Tue, 2004-01-13 at 19:05, Tom Lane wrote:
> Dave Cramer <pg@fastcrypt.com> writes:
> > Sorry folks, this is a red-herring, my hack didn't have anything to do
> > with it.
> 
> In that case you could provide a self-contained example?  I tried this
> a few times in the regression database:
> 
> select * into temp a from tenk1; drop table a;
> 
> and saw no problem in either CVS tip or 7.4.*.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly
> 
-- 
Dave Cramer
519 939 0336
ICQ # 1467551


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

0
pg
1/14/2004 1:56:26 AM
Dave Cramer <pg@fastcrypt.com> writes:
> I can't recreate it either, it is only happening on my customers
> machines, which are using an older version of redhat (7.2) and gcc 2.96

> Is it possible these versions are relevant to the issue?

Hmm.  Compiler bug maybe?  I can't recall if gcc 2.96 had a good
reputation or not.  You might try backing off the optimization level
and see if the behavior changes.  Also see if there are any errata
available for that compiler package.

Also, is this just one machine or several?  If only one, I'd try
reindexing that index and see if that helps.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faqs/FAQ.html

0
tgl
1/14/2004 2:16:38 AM
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Hmm.  Compiler bug maybe?  I can't recall if gcc 2.96 had a good
> reputation or not.  

2.96's reputation is of being *THE* canonical bad version of gcc.

mplayer for example has a configure check that specifically makes it difficult
to compile with 2.96 without reading large warnings because they've had too
many bug reports get tracked down to it:

    Note for gcc 2.96 users: Some versions of this compiler are known to miscompile
    mplayer and lame (which is used for mencoder).  If you get compile errors,
    first upgrade to the latest 2.96 release (minimum 2.96-85) and try again.
    If the problem still exists, try with gcc 3.x (or 2.95.x) *BEFORE* reporting
    bugs!

            GCC 2.96 IS NOT AND WILL NOT BE SUPPORTED BY US !

-- 
greg


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org

0
gsstark
1/14/2004 2:55:11 AM
On Tue, 2004-01-13 at 21:16, Tom Lane wrote:
> Dave Cramer <pg@fastcrypt.com> writes:
> > I can't recreate it either, it is only happening on my customers
> > machines, which are using an older version of redhat (7.2) and gcc 2.96
> 
> > Is it possible these versions are relevant to the issue?
> 
> Hmm.  Compiler bug maybe?  I can't recall if gcc 2.96 had a good
> reputation or not.  You might try backing off the optimization level
> and see if the behavior changes.  Also see if there are any errata
> available for that compiler package.

Thanks for the advice, I'm going to do more tests to try to isolate it
> 
> Also, is this just one machine or several?  If only one, I'd try
> reindexing that index and see if that helps.

Actually the hack checks for oids, and doesn't make the index, if there
isn't an oid in the table, so I tried it with a table without oids, and
it still occurs.


Thanks for the replies; I'll post if I find something relevant.
> 
> 			regards, tom lane
> 
-- 
Dave Cramer
519 939 0336
ICQ # 1467551


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

0
pg
1/14/2004 3:14:40 AM
Dave Cramer <pg@fastcrypt.com> writes:
> Actually the hack checks for oids, and doesn't make the index, if there
> isn't an oid in the table, so I tried it with a table without oids, and
> it still occurs.

My thought was that at this point the indexes on pg_attribute are very
possibly corrupt, and so just removing whatever initially caused that
corruption won't necessarily cause the error messages to stop.  You
should reindex pg_attribute to get back into a good state.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

0
tgl
1/14/2004 4:07:31 AM
Ok, that seems to have fixed it, so my next question is how did it get
corrupt?

Dave
On Tue, 2004-01-13 at 23:07, Tom Lane wrote:
> Dave Cramer <pg@fastcrypt.com> writes:
> > Actually the hack checks for oids, and doesn't make the index, if there
> > isn't an oid in the table, so I tried it with a table without oids, and
> > it still occurs.
> 
> My thought was that at this point the indexes on pg_attribute are very
> possibly corrupt, and so just removing whatever initially caused that
> corruption won't necessarily cause the error messages to stop.  You
> should reindex pg_attribute to get back into a good state.
> 
> 			regards, tom lane
> 
-- 
Dave Cramer
519 939 0336
ICQ # 1467551


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

0
pg
1/14/2004 12:48:32 PM
Dave Cramer <pg@fastcrypt.com> writes:
> Ok, that seems to have fixed it, so my next question is how did it get
> corrupt?

The nearest culprit seems to be whatever you did in analyze.c ;-).  It's
not obvious to me how analyze.c would manage to mess up an index, since
it's nowhere near the index-handling code, but I'd sure want to examine
your patch before looking further afield for an explanation.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

0
tgl
1/14/2004 2:40:42 PM
Reply: