Message-ID: <45D0B8A4.7000602@archonet.com>
Date: Mon, 12 Feb 2007 18:57:40 +0000
From: Richard Huxton <dev@archonet.com>
User-Agent: IceDove 1.5.0.9 (X11/20061220)
MIME-Version: 1.0
To: Ezequias Rodrigues da Rocha <ezequias.rocha@gmail.com>
Cc: Scott Marlowe <smarlowe@g2switchworks.com>,
	pgsql-sql@postgresql.org, pgsql-admin@postgresql.org
Subject: Re: [SQL] Deadlock on transaction
References: <55c095e90702120943v2909044eo91445b0eda3958c7@mail.gmail.com>	
	<1171302488.3565.15.camel@state.g2switchworks.com>	
	<55c095e90702121008u6d3d27c0m16e52d63f97c3e7d@mail.gmail.com>	
	<45D0B565.9060402@archonet.com>
	<55c095e90702121047x1c66b098xbcf0d308195ff584@mail.gmail.com>
In-Reply-To: <55c095e90702121047x1c66b098xbcf0d308195ff584@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ezequias Rodrigues da Rocha wrote:
> 2007/2/12, Richard Huxton <dev@archonet.com>:
>>
>> Ezequias Rodrigues da Rocha wrote:
>> > I mean really deadlock. Other transactions can't access the database
>> until
>> > the main transaction is complete. A question:
>> >
>> > PostgreSQL doesn't permit multiple transactions concurrently ?
>>
>> PG has quite good concurrency behaviour. And "can't access the database"
>> isn't anything to do with locking - clients should still be able to log
>> in.
>>
>> We'll need more details:
>> 1. How do you know this is a deadlock? You haven't shown us what's in
>> pg_locks, but I assume you've identified the problem there.
> 
> 
> I knew becouse my Delphi application reports it to me. If there is anything
> in pg_log I could see it to you.

You still aren't showing us the deadlock in pg_locks. How does your 
Delphi application decide there is a deadlock? I can see how it might 
know a timeout has occurred, but not how it determines what any other 
connections to the database might be doing. You do know the difference 
between just waiting for locks and having a deadlock?

http://en.wikipedia.org/wiki/Deadlock

> 2. What data are you loading, to what tables?
> 
> Simple data but allways with the same username (does it make any difference
> ?)
> 
> 3. Are there any foreign-keys or triggers we would need to know about?
> 
> No.

Then you don't have a deadlock. Without multiple processes trying to 
take the same locks in different orders you don't get deadlock.

> Ps: When I do not use transactions the connections does not lock to other
> users.

You are always using transactions. There is no out-of-transaction way to 
execute a statement in PostgreSQL. You can't lock either a connection or 
users, just rows.

OK - I think you'd better give a full example. Can you show us:
1. What query or queries you execute to load the data?
2. What query or queries you think are causing "deadlock"?
3. The order they execute in and what error you get.

-- 
   Richard Huxton
   Archonet Ltd