Re: do foreign key checks lock parent table ?

swalker@iglou.com wrote:
>
> So turning intially deferred on is a suitable solution?  It seems
> to work OK in this simple test case.

    It might change the behaviour of your application. If you set
    the constraints deferred, they aren't checked at insert  time
    and  the  PK's  aren't locked then either. So after doing the
    INSERT or UPDATE successfully, someone else can still  remove
    the primary key referenced in your rows without any problems.
    When  you  commit  your  transaction   then,   the   deferred
    constraints will fail and the COMMIT results in a ROLLBACK.


Jan

>
> On Tue, 2 Apr 2002, Stephan Szabo wrote:
> > The locks being grabbed are a bit stronger than they need to be
> > (if you want more info, there was a bit of discussion on -hackers
> > recently).  The updates should block updates on parent of the
> > referenced row but don't need to block other child updates but there's
> > no current lock level that is quite right.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>


--

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