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
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.
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.
regards, tom lane