RE: [SQL] Deleting indexes before vacuum? - Mailing list pgsql-sql

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Monday, November 22, 1999 12:18 PM
> To: Hiroshi Inoue
> Cc: pgsql-sql@postgreSQL.org
> Subject: Re: [SQL] Deleting indexes before vacuum? 
> 
> 
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> >> I have been toying with the notion of ripping out the existing VACUUM
> >> index handling code and putting in fresh code that would simply do an
> >> index drop and rebuild ;-).
> 
> > Shouldn't vacuum preserve consistency even in case of abort ?
> 
> That would be nice, certainly, but the existing code doesn't guarantee
> it either, and I don't see how we could guarantee it by any method.
> If you're moving tuples around then you are going to have some
> inconsistent intermediate states :

AFAIK,moving tuples in vacuum doesn't cause inconsistency.
Time qualification doesn't regard tuples as valid which are newly
being insert(mov)ed until the internal commit of vacuum.
Index tuples are inserted corrsponding to being inserted tuples
i.e index tuples are held for both being deleted and being inserted
heap tuples.
After the internal commit of vacuum,old delet(mov)ed tuples are
no longer valid and newly insert(mov)ed tuples become valid
and from this point we could freely delete index tuples correponding
to deleted heap tuples.

>-(.  However, the big problem in
> that respect is an abort while vacuum is reshuffling the data in the
> table itself; changing our approach to index vacuuming isn't going
> to make any difference there.  Once the table is finished and vacuum
> moves on to fixing the indexes, an abort would leave the index(es)
> corrupt but the table data should be OK.  So the issue is how to
> recover the indexes after that happens.
> 
> > Rebuiding indexes in vacuum has a big flaw that index may vanish in
> > case of abort and we may have to recreate index manually.
> 
> The index won't "vanish" --- I see no reason to touch the system-table
> entries for it.  The data in the index might be corrupt, but that can
> happen now.
>

I have thought about rebuilding indexes in vacuum only for speeding things 
up.  Removing(or invalidating) indexes is necessary if we rebuild indexes
in vacuum and want to preserve consistency between heap and index
relations even in case abort.
There's no inconsistency if there's no index.

> ISTM that a big advantage of the rebuild approach is that if something
> does go wrong during the index-fixing phase, you can try to recover just
> by doing another vacuum.  That strikes me as less "manual" than dropping
> and rebuilding the indexes, which is the only available recovery path
> now.  It might even work for an index on a system table...
>

Hmm,if system indexes corrupt,we may not be able to start postmaster
as Jan says.  There should be an utility which is executed in bootstrap
mode if Index recovery is really needed.
Regards.

Hiroshi Inoue
Inoue@tpf.co.jp