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