Re: Deadlock Problem - Mailing list pgsql-general

From Andrew Sullivan
Subject Re: Deadlock Problem
Date
Msg-id 20040316142039.GA5209@phlogiston.dyndns.org
Whole thread Raw
In response to Re: Deadlock Problem  (Matthias Schmitt <freak002@mmp.lu>)
List pgsql-general
On Tue, Mar 16, 2004 at 09:50:43AM +0100, Matthias Schmitt wrote:
> begin;
> update the_test set name = 'still alive' where id = 1;
>
> To keep the transaction open I did not issue any commit or rollback
> command.



>
> shell no 2:
>
> begin;
> update the_test set name = 'still alive' where id = 1;
>
> The second shell hangs now forever. The pg_locks table shows:

First, you haven't tried to COMMIT anywhere.  Nothing will happen in
that case.  For all you know, one of these is going to ROLLBACK and
resolve the lock on its own.  The second one you issue is just going
to sit there, sure.

You actually haven't describe a deadlock here.  This is just a
straightforward wait-and-see lock for transaction 2: that update
statement will indeed wait forever until it sees what 1 has done.
You'd only get a deadlock in case transaction 2 first did something
that T1 _next_ had to depend on.  You really need two conflicting
locks for a deadlock to happen.

A

--
Andrew Sullivan  | ajs@crankycanuck.ca
The fact that technology doesn't work is no bar to success in the marketplace.
        --Philip Greenspun

pgsql-general by date:

Previous
From: BRINER Cedric
Date:
Subject: pg module python
Next
From: Tom Lane
Date:
Subject: Re: Deadlock Problem