On Mon, 5 Jan 2004, Rod Taylor wrote:
> On Mon, 2004-01-05 at 14:48, Stephan Szabo wrote:
> > 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
> >
On Mon, 2004-01-05 at 14:48, Stephan Szabo wrote:
> 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. I
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
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
On Mon, 5 Jan 2004, Bruno Wolff III wrote:
> On Mon, Jan 05, 2004 at 11:33:40 -0500,
> Vivek Khera <[EMAIL PROTECTED]> wrote:
> >
> > Thanks. Then it sorta makes it moot for me to try deferred checks,
> > since the Pimary and Foreign keys never change once set. I wonder
> > what is making the
On Jan 5, 2004, at 1:38 PM, Bruno Wolff III wrote:
I think this is probably the issue with foreign key checks needing an
exclusive lock, since there is no shared lock that will prevent
deletes.
That was my original thought upon reading all the discussion of late
regarding the FK checking locks.
On Mon, Jan 05, 2004 at 11:33:40 -0500,
Vivek Khera <[EMAIL PROTECTED]> wrote:
>
> Thanks. Then it sorta makes it moot for me to try deferred checks,
> since the Pimary and Foreign keys never change once set. I wonder
> what is making the transactions appear to run lockstep, then...
I think t
> "CK" == Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> One more question: does the FK checker know to skip checking a
>> constraint if the column in question did not change during an update?
CK> As of 7.4, yes the check is skipped.
Thanks. Then it sorta makes it moot for me to tr
One more question: does the FK checker know to skip checking a
constraint if the column in question did not change during an update?
That is, if I have a user table that references an owner_id in an
owners table as a foreign key, but I update fields other than owner_id
in the user table, will it st
One more question: does the FK checker know to skip checking a
constraint if the column in question did not change during an update?
That is, if I have a user table that references an owner_id in an
owners table as a foreign key, but I update fields other than owner_id
in the user table, will it s
I'm observing that when I have many processes doing some work on my
system that the transactions run along almost in lockstep. It appears
from messages posted here that the foreign keys are acquiring and
holding locks during the transactions, which seems like it would cause
this behavior.
I'd lik
11 matches
Mail list logo
