On Tue, 18 Feb 2003, Gavin Sherry wrote:
GS>Perhaps the change that needs to be made is:
GS>
GS>if(IsUnderPostmaster)
GS> elog(ERROR,"You cannot run REINDEX INDEX in multi-user mode");
GS>
GS>to ReindexIndex() or some other appropriate place (with a better error
GS>message).
GS>
GS>Gavin
It i
On Mon, 17 Feb 2003, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> 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
Neil Conway <[EMAIL PROTECTED]> 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 re
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
Neil Conway <[EMAIL PROTECTED]> writes:
> Naturally, this situation is not a very common one. But it seems to me
> that the practice of acquiring locks in REINDEX in an inconsistent order
> is asking for trouble: REINDEX TABLE locks the heap rel first, followed
> by any indexes of the heap rel, but
I noticed a pretty obscure deadlock condition with REINDEX in CVS HEAD:
client1:
nconway=# create table a (b int unique, c int unique);
CREATE TABLE
nconway=# begin;
BEGIN
nconway=# lock table a in access exclusive mode;
LOCK TABLE
client2:
nconway=# reindex index a_b_key;
< blocks, waiting to
