Skip site navigation (1) Skip section navigation (2)

Re: How is this possible? (more on deadlocks)

From: Vivek Khera <khera(at)kcilink(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: How is this possible? (more on deadlocks)
Date: 2004-08-27 19:43:25
Message-ID: x7hdqobc4i.fsf@yertle.int.kciLink.com (view raw or flat)
Thread:
Lists: pgsql-general
>>>>> "CM" == Carlos Moreno <moreno(at)mochima(dot)com> writes:

CM> Ok, now I'm really intrigued by what looks to me
CM> (possibly from a naive point of view) like a bug,
CM> or rather, a limitation on the implementation.
 [[ ... ]]
CM> I don't know about the internals of how transactions
CM> and locks and FK constraints are handled, but I'm
CM> analyzing it and describing what seems to be
CM> happening internally, based on the behaviour I
CM> observe.

FWIW I get bit by this quite a bit.  Unfortunately all the deadlock
avoidance theory doesn't help you since you're not explicitly getting
the locks, and as you see, ordering the insert/update operations such
as to avoid conflicting locks is hard to do.

If I could designate the transaction I prefer to be killed, it would
save me a lot: often my short easy to repeat transaction wins out over
some large multi-thousand row select/insertion operation.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.                Khera Communications, Inc.
Internet: khera(at)kciLink(dot)com       Rockville, MD  +1-301-869-4449 x806
AIM: vivekkhera Y!: vivek_khera   http://www.khera.org/~vivek/

In response to

pgsql-general by date

Next:From: Tom LaneDate: 2004-08-27 19:47:56
Subject: Re: performance of IN (subquery)
Previous:From: Dino VlietDate: 2004-08-27 19:35:42
Subject: Re: help with trigger

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group