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
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 |