Re: Deadlock Problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Matthias Schmitt <freak002(at)mmp(dot)lu>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Deadlock Problem
Date: 2004-03-16 14:33:37
Message-ID: 24470.1079447617@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Matthias Schmitt <freak002(at)mmp(dot)lu> writes:
> I did the following in two psql shell environments:

> shell no 1:

> CREATE TABLE the_test (
> id int4 PRIMARY KEY,
> name varchar(32)
> );

> insert into the_test values (1, 'hello world');

> 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.

Well, of course. It has to wait to see if the previous update of the
row commits or not, so that it knows which version of the row to start
from. (In this trivial case it doesn't really matter, but in more
complex cases such as where different fields are being updated, it
does.)

This is *not* a deadlock, however, as transaction 1 is free to make
progress. The fact that you've got a client holding an open transaction
and not doing anything is a client-side design error, not a deadlock.

> Shouldn't a time-out error resolve those problems?

Sure, and it works fine:

regression=# set statement_timeout TO 10000;
SET
regression=# begin;
BEGIN
regression=# update the_test set name = 'still alive' where id = 1;
-- about ten seconds elapse, then:
ERROR: canceling query due to user request
regression=#

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2004-03-16 14:49:45 Re: Data Corruption in case of abrupt failure
Previous Message Andrew Sullivan 2004-03-16 14:20:39 Re: Deadlock Problem