> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Jan Wieck
>
> Anyway, I still think that a new implementation of reindexdb
> would be good. Some of the system indices can cause big, big
> trouble, if they get corrupted. If you would ever be faced
> with a corrupted pg_class_... index, you won't be able to
> dump any more, because the backend will fail to startup at
> all.
>
> I analyzed the problem of recreating system catalog indices
> some weeks ago, and ISTM that during bootstrap operation, ALL
> tuples are visible.
>
> I hacked in a "drop index" for the bootstrap parser, and on a
> freshly created DB some hand-made BKI script ran smooth and
> recreated all the indices well. But it failed on the
> regression DB, bacause it bombed out with duplicate errors.
> First I was a little puzzled about it, because I allways
> thought that only vacuum removes index tuples. So it could
> only be the main tuples visibility that prevents from dup
> errors between vacuum times.
>
> Thus, IMHO there should be another command added to the
> bootstrap parser. This would recreate ALL existing indices
> (system and user ones), but tell the visibility code somehow
> to ignore deleted tuples. I don't have the time to do it now,
> so at least I'd like to have a TODO item for it.
>
I may be able to implement reindex command unless you have
the time to do it.
Different from your suggestion,I would implement it in a non-bootstrap
standalone postgres with the new option by which PostgreSQL ignores
system indexes.
Comments ?
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp