Re: [HACKERS] temp table oddness?

> Man, this example has bugs just crawling all over it.
> 
> I did
> 1. create plain table u1, insert "1" twice
> 2. start new backend
> 3.
> regression=> create temp table u1(i int primary key);
> NOTICE:  CREATE TABLE/PRIMARY KEY will create implicit index 'u1_pkey' for table 'u1'
> ERROR:  Cannot create unique index. Table contains non-unique values
> regression=> drop table u1;
> DROP
> regression=> \q

Again, it is because the index is done in the same transaction.

> 
> Although psql quits cleanly enough, the underlying backend has
> coredumped, as you will discover if you have any other active backends.
> The dump is an assert failure at
> 
> #6  0x15bb1c in ExceptionalCondition (
>     conditionName=0x2fdcc "!((bool)((void*)(tuple) != ((void *)0)))",
>     exceptionP=0x40009a58, detail=0x0, fileName=0x7ae4 "\003", lineNumber=1127)
>     at assert.c:72
> #7  0x9c4a0 in index_destroy (indexId=150537) at index.c:1127
> #8  0x15b8f0 in remove_all_temp_relations () at temprel.c:97
> #9  0x113f64 in shmem_exit (code=0) at ipc.c:190
> #10 0x113e64 in proc_exit (code=0) at ipc.c:136
> #11 0x12244c in PostgresMain (argc=5, argv=0x40003090, real_argc=5,
>     real_argv=0x7b033324) at postgres.c:1614
> 
> Apparently, temp index creation registers the temp index with temprel.c
> before the index is filled.  Then, the "duplicate values" error aborts
> creation of the index --- but the entry in temprel.c's list is still
> there.  When remove_all_temp_relations tries to delete the index,
> kaboom.

Yep.  Wouldn't the best way be to have the temp system record the
transaction id used, and to invalidate all temp entries associated with
an aborted transaction.  That is how the cache code works, so it seems
it should be extended to the temp code.

> 
> Although this particular error presumably won't be possible after we
> fix the problem that the index is looking at the wrong underlying table,
> there are other possible errors in index creation, so I think we gotta
> deal with this problem too.
> 
> A quick and dirty fix might be to make index_destroy return quietly
> if it's asked to destroy a nonexistent index.  A better fix would be
> to make remove_all_temp_relations check whether the rel it's trying to
> destroy still exists --- this should happen for plain rels as well as
> indexes, probably, since heap_destroy_with_catalog doesn't like being
> asked to destroy a nonexistent table either.

I say let's leave these alone.  Their aborting on removal of
non-existant stuff helps us see bugs that could be masked by proposed
fix.

The temp table code was very small, and relies on the cache code, and
the fact all relname lookups happen through the cache.  I am suprised it
has worked as well as it has.


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026