Re: REINDEX ALL and CLUSTER ALL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: REINDEX ALL and CLUSTER ALL
Date: 2002-08-27 20:08:53
Message-ID: 3228.1030478933@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"scott.marlowe" <scott(dot)marlowe(at)ihs(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2002-08-27 20:10:56 Re: Open 7.3 items
Previous Message Lamar Owen 2002-08-27 20:05:36 Re: Open 7.3 items