Re: inserts on a transaction blocking other inserts

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Rachit Siamwalla <rachit(at)ensim(dot)com>
Cc: "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: inserts on a transaction blocking other inserts
Date: 2001-05-16 19:55:52
Message-ID: 200105161955.PAA05406@jupiter.jw.home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Rachit Siamwalla wrote:
> [...]
>
> It shouldn't block there. Basically it happens when two transactions try to
> insert something into tables (doesn't have to be the same one) which both
> have a foreign key constraint to a common key. I did some poking around and
> luckily did find something in the archives that was similar here:

The required lock to ensure that the PK doesn't get changed
after the constraint checked for it's existence would be a
shared read lock. Unfortunately, there is no SQL syntax
doing a SELECT that does it. So the only way for now is
doing an exclusive write lock with SELECT FOR UPDATE.

Not fixed in 7.1.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Hollomon 2001-05-16 20:35:33 static link of plpython/plperl - was Re: State of PL/Python build
Previous Message Jan Wieck 2001-05-16 19:29:40 Re: Grammar-problems with pl/pgsql in gram.y