Re: deadlock in REINDEX

From: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: deadlock in REINDEX
Date: 2003-02-18 01:10:30
Message-ID: Pine.LNX.4.21.0302181206580.19114-100000@linuxworld.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 17 Feb 2003, Tom Lane wrote:

> Neil Conway <neilc(at)samurai(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2003-02-18 01:34:02 Re: IpcSemaphoreKill: ...) failed: Invalid argument
Previous Message Tom Lane 2003-02-18 00:56:07 Re: deadlock in REINDEX