Skip site navigation (1) Skip section navigation (2)

Re: Soft deadlocks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Soft deadlocks
Date: 2007-06-25 15:23:48
Message-ID: 29104.1182785028@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> I'm trying to understand what a soft deadlock is as described by deadlock.c.

> As best I understand if a process, A, is waiting for a lock and is being
> blocked only because someone, B, is ahead of it in the queue but hasn't been
> granted the conflicting lock we want to jump A ahead of B.

No, we only do that if it breaks a deadlock.  In your example there is
no reason to move process A ahead of B.

A more typical situation is like this:

Process A:
	begin;
	select * from T where ...;
	-- now A holds AccessShareLock on T

Process B:
	lock table T;
	-- wants AccessExclusiveLock on T, blocks waiting for A

Process A:
	lock table T;
	-- blocks behind B?

Fairness would normally demand that A queue behind B for the
AccessExclusiveLock, but if we do that we have a deadlock.
So we spring A ahead of B and let it have the AccessExclusiveLock
out of turn.

This is just the base case; you can get into similar situations
involving more than one lockable object and more than two processes.
I believe that the above case is caught by the test in ProcSleep and
A will be granted the lock upgrade without blocking at all; but any
more-complex situation will only be discovered when someone runs the
deadlock checker.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-06-25 15:25:35
Subject: Re: msvc and vista fun
Previous:From: Tom LaneDate: 2007-06-25 15:08:42
Subject: Re: Frustrating issue with PGXS

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group