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(at)debis(dot)com (Jan Wieck) #