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@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
