Neil Padgett <npadgett@redhat.com> writes:
> Bruce Momjian wrote:
>> One, we could have you sleep on the lock, and when you get it, release
>> it and then start acquiring the locks in the order specified again.
> I think this could work. But I worry it makes starvation even more
> likely.
I agree, it looks like a recipe for starvation.
>> Another idea is to change the lock code so instead of returning a lock
>> failure on first try, it goes to sleep for DEADLOCK seconds, and once it
>> wakes up, and determines there is no deadlock, returns a lock failure.
>> That way, it can release all the locks and do a non-timeout lock on the
>> table that failed. We would then need to release the lock and do the
>> steps outlined above.
> This is interesting. I'd like to hear what other people think about
> this.
I doubt that this works --- it still has the same fundamental problem:
that you're not telling the lock manager what it needs to know to
fulfill its responsibility of detecting deadlock. I believe I can still
produce a ping-pong undetected deadlock example with the above behavior;
it'd just take a few more processes. The issue is that you are
expecting the lock manager to detect or not detect deadlock, when you
still have some lock requests up your sleeve that it's not seen yet.
As long as you can block before presenting them all, it can never work.
> In other words it sounds like you are making a tradeoff for greater
> throughput in exchange for possibly reduced concurrency. This can be a
> design decision on our part, and might be a reasonable thing to do. How
> hard do you think it will be to tune the DEADLOCK timer to a reasonable
> value? Would it have to vary based on load?
Right now the deadlock timeout is extremely noncritical; I doubt many
people actually bother to tune it. I would rather not see us change
things in a way that makes that number become significant.
regards, tom lane
