Is REINDEX ALL safe? - Mailing list pgsql-hackers

I would guess that if someone mentioned it, then it HAS happened at least 
once, maybe more.  Would doing it in a transaction be a good idea or not?  
I'm not that familiar with the implications of doing a reindex by hand in 
a transaction.  

Since reindex was designed to fix broken indexes, it's use to reclaim 
space may awaken bugs no man has dared to dream exist before.  Or 
something like that.  

On Tue, 27 Aug 2002, Bruce Momjian wrote:

> 
> I am not sure, but it certainly makes sense that it would drop the index
> on failure.  I would never expect it to fail, however.
> 
> ---------------------------------------------------------------------------
> 
> scott.marlowe wrote:
> > 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  ^^^^^^^^^^^^^
> > 
> > 
> > On Tue, 27 Aug 2002, Bruce Momjian wrote:
> > 
> > > 
> > > REINDEX just rebuilds the index, not just drop it.  In fact, 7.3 will
> > > have a reindexdb script.
> > > 
> > > ---------------------------------------------------------------------------
> > > 
> > > scott.marlowe wrote:
> > > > On Tue, 27 Aug 2002, Bruce Momjian wrote:
> > > > 
> > > > > Christopher Kings-Lynne wrote:
> > > > > > Would it be worth adding REINDEX ALL and CLUSTER ALL as actual SQL commands?
> > > > > > This would be neat.  Plus, it means we don't have to worry about having
> > > > > > unix-only script in the distro once we have Win32 support.
> > > > > > 
> > > > > > Actually, we should just leave the 'ALL' off.  That will make them behave
> > > > > > like VACUUM without arguments...
> > > > > 
> > > > > Wow, now that is a nify idea!   Let me add it to TODO and we can get rid
> > > > > of the shell scripts entirely:
> > > > > 
> > > > >         o Allow CLUSTER to cluster all tables, remove clusterdb
> > > > >     o Allow REINDEX to rebuild all indexes, remove /contrib/reindex
> > > > > 
> > > > > If we ever get the index growth fixed, we will not need the reindex
> > > > > change, I guess, but maybe if they have some index corruption but they
> > > > > are not sure where it may be helpful.
> > > > 
> > > > Isn't it true that reindex's behavior is to simply, quietly delete the 
> > > > index?  that was reported by someone when all this was going around 
> > > > before.  I wrote my own reindex script that basically (in a single 
> > > > transaction) grabbed the definition of the index, dropped said index, then 
> > > > recreated it, then committed the transaction, so that if it failed for any 
> > > > reason, the old index was still there.
> > > > 
> > > > If reindex does "lose" the index on failure then we need to look at 
> > > > changing how it works before we recommend it as a "daily maintenance 
> > > > routine".
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: you can get off all lists at once with the unregister command
> >     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> > 
> 
>