Re: Reducing relation locking overhead

Kevin Brown <kevin(at)sysexperts(dot)com> writes:

> > The fact that you've been holding the AccessShareLock for quite a
> > long time means that the window for deadlock problems is very wide.
>
> But with respect to deadlocks, that's true only if deadlocks are
> possible, which is true only if the order of lock acquisition differs
> between transactions.

Taking locks in different orders is one way to trigger deadlocks. But it's not
the only way.

If two threads both take a shared lock on a resource, then try to upgrade it
to an exclusive lock they'll both be waiting on the other thread to release
its shared lock... And in this case they're acquiring the locks in precisely
the same order.

What I don't get from what Tom said was that he implied REINDEX would deadlock
against a regular thread acquiring a plain old exclusive lock even when it's
not also a lock upgrade. It seems to me that REINDEX should be able to get in
and get its exclusive lock and finish its job and then the other job should be
able to get its exclusive lock and complete fine.

--
greg