From: Stephan Szabo <sszabo@megazone.bigpanda.com>
To: Markus Schaber <schabi@logix-tt.com>
Cc: mario.splivalo@mobart.hr
Cc: pgsql-sql@postgresql.org
Subject: Re: Changing the transaction isolation level within the stored
Date: Thu, 26 Jan 2006 07:28:56 -0800 (PST)
Message-ID: <20060126072340.G93001@megazone.bigpanda.com> (raw)
In-Reply-To: <43D8999E.9090907@logix-tt.com>
References: <1138198348.8828.32.camel@localhost.localdomain>
<43D79132.9050900@logix-tt.com>
<1138259463.16164.4.camel@localhost.localdomain>
<43D8999E.9090907@logix-tt.com>
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;
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: sszabo@megazone.bigpanda.com, schabi@logix-tt.com, mario.splivalo@mobart.hr
Subject: Re: Changing the transaction isolation level within the stored
In-Reply-To: <20060126072340.G93001@megazone.bigpanda.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox