Re: [HACKERS] regression tests

Bruce Momjian wrote:

> >     The question is, who did  something  that  could  cause  this
> >     error?
>
> I am sure it was me changing the temp behavior.  I will look at it.

    Running the queries in question in gdb shows:

backend> CREATE TABLE temptest(col int);
backend> CREATE INDEX i_temptest ON temptest(col);
backend> CREATE TEMP TABLE temptest(col int);
NOTICE:  trying to delete a reldesc that does not exist.
NOTICE:  trying to delete a reldesc that does not exist.
backend> CREATE INDEX i_temptest ON temptest(col);
NOTICE:  trying to delete a reldesc that does not exist.
NOTICE:  trying to delete a reldesc that does not exist.
backend> DROP INDEX i_temptest;
backend> DROP TABLE temptest;

Program received signal SIGSEGV, Segmentation fault.
0x806b47d in heap_openr (relationName=0x81c4e90 "temptest", lockmode=7)
    at heapam.c:569
569             if (RelationIsValid(r) && r->rd_rel->relkind == RELKIND_INDEX)

(gdb) print *r
$2 = {rd_fd = 65536, rd_nblocks = 184, rd_refcnt = 38017,
  rd_myxactonly = 16 '\020', rd_isnailed = 8 '\b', rd_isnoname = 0 '\000',
  rd_unlinked = 0 '\000', rd_am = 0xb8, rd_rel = 0x2, rd_id = 2,
  rd_lockInfo = {lockRelId = {relId = 403, dbId = 131072}}, rd_att = 0xb8,
  rd_rules = 0x8109480, rd_istrat = 0x0, rd_support = 0xb8, trigdesc = 0x2}

    The  problem  at this point is that r->rd_rel is 0x2, causing
    the SIGSEGV.  But I assume the real problem  occured  earlier
    where  the  notice's  came from. The relation descriptor must
    have gotten messed up somehow during the CREATE TEMP TABLE.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #