Re: deadlock in REINDEX

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: deadlock in REINDEX
Date: 2003-02-18 00:21:47
Message-ID: 1045527707.32092.38.camel@tokyo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2003-02-17 at 18:39, Tom Lane wrote:
> > I was thinking of changing reindex_index() to acquire an AccessShareLock
> > on the index in question, find its parent rel ID, release the lock, then
> > acquire an AccessExclusiveLock on the parent rel, followed by an
> > AccessExclusiveLock on the index in question.
>
> 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).

Whether or not that solution actually works, ISTM there must be *some*
method of locking that is free of deadlocks -- saying "oh well, it's not
a common case anyway" doesn't strike me as being satisfactory :-\

Cheers,

Neil
--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-02-18 00:56:07 Re: deadlock in REINDEX
Previous Message Curtis Faith 2003-02-17 23:52:50 Re: Brain dump: btree collapsing