Re: Reducing relation locking overhead - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Reducing relation locking overhead
Date
Msg-id 87mzjidx2d.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Reducing relation locking overhead  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Reducing relation locking overhead  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:

> The problem is that you need to upgrade the lock at the end of the
> operation.  This is very deadlock prone, and likely to abort the whole
> operation just when it's going to finish.  Is this a showstopper?  Tom
> seems to think it is.  I'm not sure anyone is going to be happy if they
> find that their two-day reindex was aborted just when it was going to
> finish.

How likely is this really to be a problem in this particular case? Obviously
if two people try to reindex the same index they'll have a problem, but that's
not really a problem. (Postgres should probably do something to block that up
front rather than wait until the end to fail.)

Other than that case is there any other case the reindex could deadlock with?

I'm a bit hampered thinking about this because I'm not really sure exactly
what locks a reindex needs and what else takes those locks.


-- 
greg



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Reducing relation locking overhead
Next
From: Neil Conway
Date:
Subject: Re: Upcoming PG re-releases