| 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: | Whole Thread | Raw Message | 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 |