On Thu, Aug 16, 2007 at 01:21:43AM -0400, Tom Lane wrote:
> Decibel! <[EMAIL PROTECTED]> writes:
> > But... taking a quick look at RI_FKey_check in backend/utils/adt/
> > ri_triggers.c, I don't see it checking to see if the FK has changed,
> > which seems odd. I would think that if the FK fields
Decibel! <[EMAIL PROTECTED]> writes:
> But... taking a quick look at RI_FKey_check in backend/utils/adt/
> ri_triggers.c, I don't see it checking to see if the FK has changed,
> which seems odd. I would think that if the FK fields haven't changed
> that there's no need to perform the check.
Y
On Aug 15, 2007, at 1:27 PM, Dmitry Koterov wrote:
I have tested all cases, the code I quoted is complete and minimal.
All operations are non-blocking (count incrementation is non-
blocking, insertion with a foreign key is non-blocking too), but it
still generates a deadlock time to time. Del
No.
I have tested all cases, the code I quoted is complete and minimal. All
operations are non-blocking (count incrementation is non-blocking, insertion
with a foreign key is non-blocking too), but it still generates a deadlock
time to time. Deletion of the foreign key constraint completely solves
On Fri, Aug 10, 2007 at 09:38:36PM +0400, Dmitry Koterov wrote:
> Hello.
>
> I have a number of deadlock because of the foreign key constraint:
>
> Assume we have 2 tables: A and B. Table A has a field fk referenced to
> B.idas a foreign key constraint.
>
>
> -- transaction #1
> BEGIN;
> ...
>
Hello.
I have a number of deadlock because of the foreign key constraint:
Assume we have 2 tables: A and B. Table A has a field fk referenced to
B.idas a foreign key constraint.
-- transaction #1
BEGIN;
...
INSERT INTO A(x, y, fk) VALUES (1, 2, 666);
...
END;
-- transaction #2
BEGIN;
UPDATE B
