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 haven't
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;
...
INSERT INTO
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
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.
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.
You
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
