Tom Lane wrote:
Hannes Dorbath <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
