Re: REINDEX ALL and CLUSTER ALL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: REINDEX ALL and CLUSTER ALL
Date
Msg-id 3228.1030478933@sss.pgh.pa.us
Whole thread Raw
In response to Re: REINDEX ALL and CLUSTER ALL  ("scott.marlowe" <scott.marlowe@ihs.com>)
Responses Re: REINDEX ALL and CLUSTER ALL  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
"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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Lamar Owen
Date:
Subject: Re: Open 7.3 items
Next
From: Rod Taylor
Date:
Subject: Re: Open 7.3 items