"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 :-(. 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.
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...
regards, tom lane
