| From: | Hannes Dorbath <light(at)theendofthetunnel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Index trouble with 8.3b4 |
| Date: | 2008-01-13 21:01:49 |
| Message-ID: | 478A7C3D.5060406@theendofthetunnel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
Tom Lane wrote:
> Hannes Dorbath <light(at)theendofthetunnel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | x asasaxax | 2008-01-13 21:55:58 | Satisfactory Query Time |
| Previous Message | Tom Lane | 2008-01-13 20:54:50 | Re: Index trouble with 8.3b4 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-01-13 21:59:47 | Distinguishing autovacuum activity in pg_stat_activity |
| Previous Message | Webb Sprague | 2008-01-13 20:59:02 | Re: Postgresql Materialized views |