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  (Hannes Dorbath <light@theendofthetunnel.de>)
Re: Index trouble with 8.3b4  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Webb Sprague"
Дата:
Сообщение: Re: Postgresql Materialized views
Следующее
От: Tom Lane
Дата:
Сообщение: Distinguishing autovacuum activity in pg_stat_activity