Kevin Brown <[EMAIL PROTECTED]> writes:
> And now I see why, since it will introduce deadlocks (sigh). But what
> of the other rule (always acquiring locks against the table before the
> index)? You may have stopped reading at the above...
We already do that.
> One thing I don't quite understand about the discussion is why there's
> particular attention being paid to deadlocks with respect to REINDEX
> when it clearly can happen in the general case when lock promotion is
> involved. Why is REINDEX special here?
Because what people are asking for is an on-line REINDEX, ie, something
that will go through in the presence of concurrent updates. Most other
sorts of DDL changes to tables take exclusive locks so they don't have
to worry about concurrency. (There is of course some risk of deadlock
from the exclusive lock, but at least it happens *before* you've done
a lot of work not *after*.)
> Additionally, I was under the impression that normal INSERTs, UPDATEs,
> and DELETEs didn't generally need to acquire AccessExclusiveLock,
> because of MVCC. If that's the case, then aren't the operations that
> could deadlock REINDEX relatively rare?
The concern about deadlock applies to the various proposals that involve
upgrading to a write-prevention lock at some late point in the process.
That clearly has the potential to deadlock against relatively weak lock
requests.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
