Re: undead index - Mailing list pgsql-general

From Tom Lane
Subject Re: undead index
Date
Msg-id 11539.1304695109@sss.pgh.pa.us
Whole thread Raw
In response to Re: undead index  (Jens Wilke <jens.wilke@affinitas.de>)
Responses Re: undead index  (Jens Wilke <jens.wilke@affinitas.de>)
List pgsql-general
Jens Wilke <jens.wilke@affinitas.de> writes:
> On Wednesday 04 May 2011 17:32:50 Tom Lane wrote:
>> Hmm, is this an autogenerated index?

> I don't think so.
> And to confirm, that i really deleted the new cluster between the pg_upgrade
> run and the dump|restore i did it again and was able to revive this index
> again:

> foo=# \d+ foo.bar_idx
>       Index "foo.bar_idx"
>   Column  |         Type          | Definition | Storage  | Description
> ----------+-----------------------+------------+----------+-------------
>  ulq_guid | character varying(24) | ulq_guid   | extended |
> btree, for table "foo.foo"

> But it's again not in the pg_dumpall output, using the same binary like for
> the dump|restore.

Well, if you don't see it in the pg_dumpall script, but running that
script creates the index, then I'd say it's autogenerated.  Possibly if
you showed us the actual (not obfuscated) table declaration, associated
constraint declarations, and resulting index definition, things would be
clearer.

            regards, tom lane

pgsql-general by date:

Previous
From: Daniele Varrazzo
Date:
Subject: psql and query buffer mangling
Next
From: Alan Hodgson
Date:
Subject: Re: Locale and UTF8 for template1 in 8.4.4