On Mon, 5 Jan 2004, Vivek Khera wrote:

> On Jan 5, 2004, at 1:57 PM, Stephan Szabo wrote:
> > But, if he's updating the fk table but not the keyed column, it should
> > no
> > longer be doing the check and grabbing the locks.  If he's seeing it
> > grab
> > the row locks still a full test case would be handy because it'd
> > probably
> > mean we missed something.
> >
> I'm not *sure* it is taking any locks.  The transactions appear to be
> running lock step (operating on different parts of the same pair of
> tables) and I was going to see if deferring the locks made the
> difference.  It is my feeling now that it will not.  However, if there
> is a way to detect if locks are being taken, I'll do that.  I'd like to
> avoid dropping and recreating the foreign keys if I can since it takes
> up some bit of time on the table with 20+ million rows.

The only way I can think of to see the locks is to do just one of the
operations and then manually attempting to select for update the
associated pk row.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to