Re: Index trouble with 8.3b4
От | Hannes Dorbath |
---|---|
Тема | Re: Index trouble with 8.3b4 |
Дата | |
Msg-id | 478A7C3D.5060406@theendofthetunnel.de обсуждение исходный текст |
Ответ на | Re: Index trouble with 8.3b4 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Index trouble with 8.3b4
Re: Index trouble with 8.3b4 |
Список | pgsql-hackers |
Tom Lane wrote: > Hannes Dorbath <light@theendofthetunnel.de> writes: >> This is a general thing I'd like to ask. If the creation of an index >> fails, why is it nevertheless there? > > It's a rather ugly consequence of the fact that CREATE INDEX > CONCURRENTLY requires more than one transaction. If the later ones > fail, the invalid index is still there. > > It'd be nice to clean that up sometime, but don't hold your breath. OK, I have my GIN failure back with CSV-HEAD: test=# UPDATE test SET tsv = to_tsvector(text); UPDATE 753100 test=# CREATE INDEX CONCURRENTLY "ts_test_tsv" ON "public"."test" USING gin ("tsv"); ERROR: item pointer (8,23) already exists test=# drop INDEX ts_test_tsv ; DROP INDEX test=# CREATE INDEX CONCURRENTLY "ts_test_tsv" ON "public"."test" USING gin ("tsv"); CREATE INDEX test=# I have a hard time to pin it down. Currently all I can say is: It happens the first time after I bulk load data into that table. I cannot catch it with pg_dump -- after a restore it works. I can reproduce it here more or less reliable. Maybe I should just bzip $PGDATA and send it. -- Best regards, Hannes Dorbath
В списке pgsql-hackers по дате отправления: