X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by postgresql.org (Postfix) with ESMTP id 3F0459DC809
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Thu, 26 Jan 2006 11:32:43 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 19045-06
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Thu, 26 Jan 2006 11:32:45 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210])
	by postgresql.org (Postfix) with ESMTP id C8C7E9DC800
	for <pgsql-sql@postgresql.org>; Thu, 26 Jan 2006 11:32:38 -0400 (AST)
Received: by megazone.bigpanda.com (Postfix, from userid 1001)
	id AF9C035FBD; Thu, 26 Jan 2006 07:28:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by megazone.bigpanda.com (Postfix) with ESMTP
	id AD84035FBC; Thu, 26 Jan 2006 07:28:56 -0800 (PST)
Date: Thu, 26 Jan 2006 07:28:56 -0800 (PST)
From: Stephan Szabo <sszabo@megazone.bigpanda.com>
To: Markus Schaber <schabi@logix-tt.com>
Cc: mario.splivalo@mobart.hr, pgsql-sql@postgresql.org
Subject: Re: Changing the transaction isolation level within the stored
In-Reply-To: <43D8999E.9090907@logix-tt.com>
Message-ID: <20060126072340.G93001@megazone.bigpanda.com>
References: <1138198348.8828.32.camel@localhost.localdomain>
	<43D79132.9050900@logix-tt.com>
	<1138259463.16164.4.camel@localhost.localdomain>
	<43D8999E.9090907@logix-tt.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.144 required=5 tests=[AWL=0.144]
X-Spam-Score: 0.144
X-Spam-Level: 
X-Archive-Number: 200601/185
X-Sequence-Number: 23974


On Thu, 26 Jan 2006, Markus Schaber wrote:


> AFAIK, in PostgreSQL normal SQL commands cannot create deadlocks at all,
> the only way to introduce deadlocks is to issue LOCK commands to take
> locks manually. And for this rare case, PostgreSQL contains a deadlock
> detection routine that will abort one of the insulting transactions, and
> the others can proceed.

That's not true.  See all the complaints about pre-8.1 foreign keys and
the row locks taken out by FOR UPDATE as an example.

A simpler example than the one given before (with potential timing) is:
create table t1 (a int);
create table t2 (a int);
insert into t1 values(1);
insert into t2 values(1);

T1: begin;
T2: begin;
T1: update t1 set a=3;
T2: update t2 set a=3;
T1: update t2 set a=2;
T2: update t1 set a=2;