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
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 |