Tom Lane wrote:
> "scott.marlowe" <scott.marlowe@ihs.com> writes:
> > Sorry, that should have been:
> > Isn't it true that reindex's behavior ON A FAILURE is to simply, quietly
> > delete the index? that was reported ^^^^^^^^^^^^^
>
> No.
>
> If you are doing a standalone system index rebuild (with backend -P
> switch) then REINDEX does a "TRUNCATE" of the index relation and
> rebuilds it in place. If that fails partway through, you'd be left
> with a corrupted index ... which presumably is the same problem you
> started with, so I'm not that concerned about it.
>
> The TRUNCATE approach is also used for rebuilding indexes on shared
> system relations (pg_database, pg_shadow, pg_group). This seems
> necessary since REINDEX has no way to update pg_class.relfilenode in
> databases other than the current one.
>
> In all other cases the rebuild is rollback-able, and a failure should
> leave you exactly where you were before.
>
>
> Given these facts I think it would be a bad idea to include the shared
> system relations in any automatic "REINDEX ALL" command. One could
> make a good argument that any such command should skip *all* system
> tables, actually.
Yes, absolutely. REINDEX is not like vacuum. It needs to skip all
system tables, I think. Those indexes are tied into backend structures.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
