From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Fuhr <mike@fuhr.org>
Cc: PostgreSQL SQL List <pgsql-sql@postgresql.org>
Cc: Joost Kraaijeveld <J.Kraaijeveld@Askesis.nl>
Subject: Re: Foreign key reference counting strategy?
Date: Sat, 14 Oct 2006 20:20:10 -0400
Message-ID: <13667.1160871610@sss.pgh.pa.us> (raw)
In-Reply-To: <20061015001126.GA20713@winnie.fuhr.org>
References: <1160828741.28838.9.camel@panoramix>
<4530EB84.4050904@logix-tt.com>
<20061014234844.GA20342@winnie.fuhr.org>
<13525.1160870286@sss.pgh.pa.us>
<20061015001126.GA20713@winnie.fuhr.org>
Michael Fuhr <mike@fuhr.org> writes:
> On Sat, Oct 14, 2006 at 07:58:06PM -0400, Tom Lane wrote:
>> No, I don't think so, because the DELETE will already be holding
>> exclusive lock on the doomed PK row, which any would-be inserters of
>> matching FK rows will be blocked on. AFAICS the DELETE should go
>> through and then the inserters will fail.
> Unless the inserters got there first. I just tested both ways; if
> the insert acquires the lock first then the delete fails, but if the
> delete acquires the lock first then the insert fails.
Well, if the inserters get a lock on the PK row before the DELETE does,
then of course. I was just disputing the assertion that doing IF EXISTS
in an after trigger would add a new way for the DELETE to fail. At that
point, any uncommitted inserts must be blocked waiting for the delete.
regards, tom lane
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: tgl@sss.pgh.pa.us, mike@fuhr.org, J.Kraaijeveld@Askesis.nl
Subject: Re: Foreign key reference counting strategy?
In-Reply-To: <13667.1160871610@sss.pgh.pa.us>
* 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