On Mon, 17 Feb 2003, Tom Lane wrote:
> Neil Conway <neilc@samurai.com> writes:
> > On Mon, 2003-02-17 at 18:39, Tom Lane wrote:
> >> If you release the lock then I think you are opening yourself to worse
> >> troubles than this one, having to do with someone renaming/deleting the
> >> table and/or index out from under you.
>
> > Presumably, the renaming/deleting operation acquires an exclusive lock
> > and then holds it until transaction commit, right? If so, then wouldn't
> > we still be okay: the REINDEX would lock the index in access share mode,
> > find the OID of the heap rel, unlock the index, lock the heap rel in
> > access exclusive mode, then try to re-open & lock the index, find that
> > it no longer exists and then elog(ERROR).
>
> That approach might be deadlock-free, but that doesn't mean it is
> surprise-free. For example, if the other guy did an ALTER TABLE RENAME
Perhaps the change that needs to be made is:
if(IsUnderPostmaster)elog(ERROR,"You cannot run REINDEX INDEX in multi-user mode");
to ReindexIndex() or some other appropriate place (with a better error
message).
Gavin
