X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id 7533E52817
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Sun, 19 Jun 2005 13:22:20 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 67407-09
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Sun, 19 Jun 2005 16:22:15 +0000 (GMT)
Received: from tigger.fuhr.org (tigger.fuhr.org [63.214.45.158])
	by svr1.postgresql.org (Postfix) with ESMTP id 2ECAD5280D
	for <pgsql-sql@postgresql.org>; Sun, 19 Jun 2005 13:22:12 -0300 (ADT)
Received: from winnie.fuhr.org (winnie.fuhr.org [10.1.0.1])
	by tigger.fuhr.org (8.13.3/8.13.3) with ESMTP id j5JGM90S072887
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 19 Jun 2005 10:22:12 -0600 (MDT)
	(envelope-from mfuhr@winnie.fuhr.org)
Received: from winnie.fuhr.org (localhost [127.0.0.1])
	by winnie.fuhr.org (8.13.3/8.13.3) with ESMTP id j5JGM9pM019504;
	Sun, 19 Jun 2005 10:22:09 -0600 (MDT)
	(envelope-from mfuhr@winnie.fuhr.org)
Received: (from mfuhr@localhost)
	by winnie.fuhr.org (8.13.3/8.13.3/Submit) id j5JGM9qJ019503;
	Sun, 19 Jun 2005 10:22:09 -0600 (MDT) (envelope-from mfuhr)
Date: Sun, 19 Jun 2005 10:22:09 -0600
From: Michael Fuhr <mike@fuhr.org>
To: Vilinski Vladimir <vilinski@web.de>
Cc: pgsql-sql@postgresql.org
Subject: Re: WHY transaction waits for another transaction?
Message-ID: <20050619162209.GA19463@winnie.fuhr.org>
References: <141218891@web.de> <20050619155811.GA18897@winnie.fuhr.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050619155811.GA18897@winnie.fuhr.org>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.005 tagged_above=0 required=5 tests=AWL
X-Spam-Level: 
X-Archive-Number: 200506/240
X-Sequence-Number: 21841

On Sun, Jun 19, 2005 at 09:58:11AM -0600, Michael Fuhr wrote:
> 
> If possible, it would be best to commit transactions that insert
> or update foreign keys as soon as possible.

I probably shouldn't have said "best" here, implying that this
solution is better than all other possibilities.  As Tom Lane pointed
out, you could also make the constraints deferrable.  If you don't
need to know about foreign key violations immediately, then deferring
the checks might be a better way to go.

-- 
Michael Fuhr
http://www.fuhr.org/~mfuhr/