Bug: Deferred FKey Check Happening on Double Update, Not Single - Mailing list pgsql-bugs

From Doug Safreno
Subject Bug: Deferred FKey Check Happening on Double Update, Not Single
Date
Msg-id CAA=+ort6kOENg7asqzq9OQ6kH0x_S5NLzWD7C=rawYgKWb+YAw@mail.gmail.com
Whole thread Raw
Responses Re: Bug: Deferred FKey Check Happening on Double Update, Not Single
List pgsql-bugs
Hello all,

I have what appears to be a bug to report. Basically, foreign key deferred locking behavior on update is inconsistent between single updates and double updates in transactions.

Imagine I have done the following setup:

DROP TABLE B;
DROP TABLE A;

CREATE TABLE A (
    ID int NOT NULL PRIMARY KEY,
    Payload int
);

CREATE TABLE B (
    ID int NOT NULL PRIMARY KEY,
    AID int REFERENCES A(ID) DEFERRABLE INITIALLY DEFERRED,
    Payload int
);

INSERT INTO A (ID, Payload) VALUES (1, 100);
INSERT INTO B (ID, AID, Payload) VALUES (1, 1, 200);

Now, in process 1, I do:

BEGIN;
SELECT * FROM A WHERE ID = 1 FOR UPDATE;

Now consider the versions A and B of process 2.

Version A:

BEGIN;
UPDATE B SET "payload" = 1000 WHERE ID = 1;
COMMIT;

Version B:

BEGIN;
UPDATE B SET "payload" = 1000 WHERE ID = 1;
UPDATE B SET "payload" = 1000 WHERE ID = 1;
COMMIT;

In process 2, if I do version A, it goes through immediately. If I do version B, it hangs, waiting for process 1 to release its lock. I would expect consistent behavior.

I was unsure from documentation which of two behaviors was the "expected" behavior.

Version: PostgreSQL 10.6 (Ubuntu 10.6-1.pgdg16.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609, 64-bit

Which one is expected? And is this really a bug?

Best,
Doug

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Segmentation Fault in logical decoding get/peek API
Next
From: PG Bug reporting form
Date:
Subject: BUG #15637: Problem insert data 【Japanese】