public inbox for [email protected]
help / color / mirror / Atom feed[PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED
6+ messages / 2 participants
[nested] [flat]
* [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED
@ 2026-02-27 09:51 Yasuo Honda <[email protected]>
2026-03-24 06:29 ` Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Fujii Masao <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Yasuo Honda @ 2026-02-27 09:51 UTC (permalink / raw)
To: pgsql-hackers
Hi,
I have encountered an unexpected behavior where the DEFERRABLE and
INITIALLY DEFERRED properties of foreign keys are lost after toggling
them from NOT ENFORCED to ENFORCED.
Background
In the Ruby on Rails framework, there is a built-in mechanism to
temporarily bypass foreign key checks while loading test data.
Currently, this is implemented using: ALTER TABLE ... DISABLE TRIGGER
ALL; ALTER TABLE ... ENABLE TRIGGER ALL;
However, this requires superuser privileges. With the newly introduced
support for "NOT ENFORCED" foreign keys in PostgreSQL 18, I am
interested in switching to: ALTER TABLE ... ALTER CONSTRAINT ... NOT
ENFORCED; ALTER TABLE ... ALTER CONSTRAINT ... ENFORCED;
This would allow the operation to be performed by the table owner
without superuser rights. However, I discovered that switching the
state back to ENFORCED unexpectedly strips away the DEFERRABLE
property.
Problem
When re-enforcing a constraint, there is a discrepancy between the
constraint definition and its underlying triggers.
While the flags in pg_constraint remain correct, the corresponding
triggers in pg_trigger (tgdeferrable and tginitdeferred) are reset to
defaults ('f') when they are reconstructed during the ENFORCED
operation.
I have attached a reproduction SQL script that demonstrates this by
comparing the values in pg_constraint and pg_trigger. In the current
PostgreSQL 18.3, you can see that the triggers lose their
deferrability even though the constraint itself is still defined as
DEFERRABLE. This causes "SET CONSTRAINTS ... DEFERRED" to fail.
After Patch
* The tgdeferrable and tginitdeferred flags in pg_trigger are
correctly preserved to match pg_constraint after the toggle, and
deferred execution works as expected.
I've attached the reproduction SQL script and a patch to fix this in
src/backend/commands/tablecmds.c. The patch and reproduction SQL
script were developed with the assistance of Claude Code. I have
reviewed and verified the code myself.
Any feedback is appreciated.
Regards,
--
Yasuo Honda
Attachments:
[application/octet-stream] 0001-Restore-tgdeferrable-and-tginitdeferred-after-NOT-EN.patch (3.3K, 2-0001-Restore-tgdeferrable-and-tginitdeferred-after-NOT-EN.patch)
download | inline diff:
From a061bdd232ee96302c0af4d4a7f4c0f901262ca9 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <[email protected]>
Date: Fri, 27 Feb 2026 17:30:04 +0900
Subject: [PATCH] Restore tgdeferrable and tginitdeferred after NOT ENFORCED
then ENFORCED
---
src/backend/commands/tablecmds.c | 2 ++
src/test/regress/expected/foreign_key.out | 18 ++++++++++++++++++
src/test/regress/sql/foreign_key.sql | 10 ++++++++++
3 files changed, 30 insertions(+)
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index b04b0dbd2a0..bc07dfe2ce8 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -12501,6 +12501,8 @@ ATExecAlterConstrEnforceability(List **wqueue, ATAlterConstraint *cmdcon,
fkconstraint->fk_matchtype = currcon->confmatchtype;
fkconstraint->fk_upd_action = currcon->confupdtype;
fkconstraint->fk_del_action = currcon->confdeltype;
+ fkconstraint->deferrable = currcon->condeferrable;
+ fkconstraint->initdeferred = currcon->condeferred;
/* Create referenced triggers */
if (currcon->conrelid == fkrelid)
diff --git a/src/test/regress/expected/foreign_key.out b/src/test/regress/expected/foreign_key.out
index 9ae4dbf1b0a..d061e51da6b 100644
--- a/src/test/regress/expected/foreign_key.out
+++ b/src/test/regress/expected/foreign_key.out
@@ -1349,6 +1349,24 @@ UPDATE pktable SET id = 10 WHERE id = 5;
-- doesn't match PK, but no error.
INSERT INTO fktable VALUES (0, 20);
ROLLBACK;
+-- verify that tgdeferrable/tginitdeferred are preserved after NOT ENFORCED -> ENFORCED
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey DEFERRABLE INITIALLY DEFERRED;
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey NOT ENFORCED;
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey ENFORCED;
+SELECT tgdeferrable, tginitdeferred FROM pg_trigger
+WHERE tgconstraint = (SELECT oid FROM pg_constraint
+ WHERE conrelid = 'fktable'::regclass
+ AND conname = 'fktable_fk_fkey');
+ tgdeferrable | tginitdeferred
+--------------+----------------
+ t | t
+ t | t
+ t | t
+ t | t
+(4 rows)
+
+-- reset
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey NOT DEFERRABLE;
-- try additional syntax
ALTER TABLE fktable ALTER CONSTRAINT fktable_fk_fkey NOT DEFERRABLE;
-- illegal options
diff --git a/src/test/regress/sql/foreign_key.sql b/src/test/regress/sql/foreign_key.sql
index 3b8c95bf893..0afed60f688 100644
--- a/src/test/regress/sql/foreign_key.sql
+++ b/src/test/regress/sql/foreign_key.sql
@@ -1023,6 +1023,16 @@ UPDATE pktable SET id = 10 WHERE id = 5;
INSERT INTO fktable VALUES (0, 20);
ROLLBACK;
+-- verify that tgdeferrable/tginitdeferred are preserved after NOT ENFORCED -> ENFORCED
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey DEFERRABLE INITIALLY DEFERRED;
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey NOT ENFORCED;
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey ENFORCED;
+SELECT tgdeferrable, tginitdeferred FROM pg_trigger
+WHERE tgconstraint = (SELECT oid FROM pg_constraint
+ WHERE conrelid = 'fktable'::regclass
+ AND conname = 'fktable_fk_fkey');
+-- reset
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey NOT DEFERRABLE;
-- try additional syntax
ALTER TABLE fktable ALTER CONSTRAINT fktable_fk_fkey NOT DEFERRABLE;
--
2.53.0
[application/octet-stream] tgdeferrable-tginitdeferred-not-restored.sql (1.5K, 3-tgdeferrable-tginitdeferred-not-restored.sql)
download
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED
2026-02-27 09:51 [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Yasuo Honda <[email protected]>
@ 2026-03-24 06:29 ` Fujii Masao <[email protected]>
2026-03-27 07:41 ` Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Yasuo Honda <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Fujii Masao @ 2026-03-24 06:29 UTC (permalink / raw)
To: Yasuo Honda <[email protected]>; +Cc: pgsql-hackers
On Fri, Feb 27, 2026 at 6:51 PM Yasuo Honda <[email protected]> wrote:
>
> Hi,
>
> I have encountered an unexpected behavior where the DEFERRABLE and
> INITIALLY DEFERRED properties of foreign keys are lost after toggling
> them from NOT ENFORCED to ENFORCED.
>
> Background
>
> In the Ruby on Rails framework, there is a built-in mechanism to
> temporarily bypass foreign key checks while loading test data.
> Currently, this is implemented using: ALTER TABLE ... DISABLE TRIGGER
> ALL; ALTER TABLE ... ENABLE TRIGGER ALL;
>
> However, this requires superuser privileges. With the newly introduced
> support for "NOT ENFORCED" foreign keys in PostgreSQL 18, I am
> interested in switching to: ALTER TABLE ... ALTER CONSTRAINT ... NOT
> ENFORCED; ALTER TABLE ... ALTER CONSTRAINT ... ENFORCED;
>
> This would allow the operation to be performed by the table owner
> without superuser rights. However, I discovered that switching the
> state back to ENFORCED unexpectedly strips away the DEFERRABLE
> property.
>
> Problem
>
> When re-enforcing a constraint, there is a discrepancy between the
> constraint definition and its underlying triggers.
> While the flags in pg_constraint remain correct, the corresponding
> triggers in pg_trigger (tgdeferrable and tginitdeferred) are reset to
> defaults ('f') when they are reconstructed during the ENFORCED
> operation.
>
> I have attached a reproduction SQL script that demonstrates this by
> comparing the values in pg_constraint and pg_trigger. In the current
> PostgreSQL 18.3, you can see that the triggers lose their
> deferrability even though the constraint itself is still defined as
> DEFERRABLE. This causes "SET CONSTRAINTS ... DEFERRED" to fail.
>
> After Patch
>
> * The tgdeferrable and tginitdeferred flags in pg_trigger are
> correctly preserved to match pg_constraint after the toggle, and
> deferred execution works as expected.
>
> I've attached the reproduction SQL script and a patch to fix this in
> src/backend/commands/tablecmds.c. The patch and reproduction SQL
> script were developed with the assistance of Claude Code. I have
> reviewed and verified the code myself.
>
> Any feedback is appreciated.
Thanks for reporting the issue and providing a patch!
I was able to reproduce the issue on the master.
The patch looks good overall, but since I'm not very familiar with this area,
I'd like to spend a bit more time reviewing the changes in detail.
Regarding the regression test, would it be better to verify not only catalog
state (e.g., pg_trigger) but also the actual behavior? For example, we could
check that a foreign key violation is not raised immediately on INSERT,
but instead at COMMIT even after ALTER CONSTRAINT ENFORCED:
ALTER TABLE ... ALTER CONSTRAINT ... NOT ENFORCED;
ALTER TABLE ... ALTER CONSTRAINT ... ENFORCED;
BEGIN;
INSERT INTO t VALUES (1);
COMMIT;
In this case, the foreign key violation should be reported at COMMIT,
even after ALTER CONSTRAINT ... ENFORCED.
Regards,
--
Fujii Masao
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED
2026-02-27 09:51 [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Yasuo Honda <[email protected]>
2026-03-24 06:29 ` Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Fujii Masao <[email protected]>
@ 2026-03-27 07:41 ` Yasuo Honda <[email protected]>
2026-03-27 15:01 ` Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Fujii Masao <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Yasuo Honda @ 2026-03-27 07:41 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: pgsql-hackers
(Resending to the list, as my previous reply went to the sender only.)
Thanks for the comment.
> Regarding the regression test, would it be better to verify not only catalog
state (e.g., pg_trigger) but also the actual behavior?
Agreed. In addition to inspecting pg_trigger contents, I've added test
cases that verify the actual runtime behavior of deferred constraints.
I've also covered INITIALLY IMMEDIATE alongside INITIALLY DEFERRED.
--
Yasuo Honda
On Tue, Mar 24, 2026 at 3:30 PM Fujii Masao <[email protected]> wrote:
>
> On Fri, Feb 27, 2026 at 6:51 PM Yasuo Honda <[email protected]> wrote:
> >
> > Hi,
> >
> > I have encountered an unexpected behavior where the DEFERRABLE and
> > INITIALLY DEFERRED properties of foreign keys are lost after toggling
> > them from NOT ENFORCED to ENFORCED.
> >
> > Background
> >
> > In the Ruby on Rails framework, there is a built-in mechanism to
> > temporarily bypass foreign key checks while loading test data.
> > Currently, this is implemented using: ALTER TABLE ... DISABLE TRIGGER
> > ALL; ALTER TABLE ... ENABLE TRIGGER ALL;
> >
> > However, this requires superuser privileges. With the newly introduced
> > support for "NOT ENFORCED" foreign keys in PostgreSQL 18, I am
> > interested in switching to: ALTER TABLE ... ALTER CONSTRAINT ... NOT
> > ENFORCED; ALTER TABLE ... ALTER CONSTRAINT ... ENFORCED;
> >
> > This would allow the operation to be performed by the table owner
> > without superuser rights. However, I discovered that switching the
> > state back to ENFORCED unexpectedly strips away the DEFERRABLE
> > property.
> >
> > Problem
> >
> > When re-enforcing a constraint, there is a discrepancy between the
> > constraint definition and its underlying triggers.
> > While the flags in pg_constraint remain correct, the corresponding
> > triggers in pg_trigger (tgdeferrable and tginitdeferred) are reset to
> > defaults ('f') when they are reconstructed during the ENFORCED
> > operation.
> >
> > I have attached a reproduction SQL script that demonstrates this by
> > comparing the values in pg_constraint and pg_trigger. In the current
> > PostgreSQL 18.3, you can see that the triggers lose their
> > deferrability even though the constraint itself is still defined as
> > DEFERRABLE. This causes "SET CONSTRAINTS ... DEFERRED" to fail.
> >
> > After Patch
> >
> > * The tgdeferrable and tginitdeferred flags in pg_trigger are
> > correctly preserved to match pg_constraint after the toggle, and
> > deferred execution works as expected.
> >
> > I've attached the reproduction SQL script and a patch to fix this in
> > src/backend/commands/tablecmds.c. The patch and reproduction SQL
> > script were developed with the assistance of Claude Code. I have
> > reviewed and verified the code myself.
> >
> > Any feedback is appreciated.
>
> Thanks for reporting the issue and providing a patch!
>
> I was able to reproduce the issue on the master.
>
> The patch looks good overall, but since I'm not very familiar with this area,
> I'd like to spend a bit more time reviewing the changes in detail.
>
> Regarding the regression test, would it be better to verify not only catalog
> state (e.g., pg_trigger) but also the actual behavior? For example, we could
> check that a foreign key violation is not raised immediately on INSERT,
> but instead at COMMIT even after ALTER CONSTRAINT ENFORCED:
>
> ALTER TABLE ... ALTER CONSTRAINT ... NOT ENFORCED;
> ALTER TABLE ... ALTER CONSTRAINT ... ENFORCED;
> BEGIN;
> INSERT INTO t VALUES (1);
> COMMIT;
>
> In this case, the foreign key violation should be reported at COMMIT,
> even after ALTER CONSTRAINT ... ENFORCED.
>
> Regards,
>
> --
> Fujii Masao
Attachments:
[application/octet-stream] v2-Restore-tgdeferrable-and-tginitdeferred-after-NOT.patch (6.7K, 2-v2-Restore-tgdeferrable-and-tginitdeferred-after-NOT.patch)
download | inline diff:
From 94c66da56a0d670c9fac96ed3fa1cc359eb6a3c5 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <[email protected]>
Date: Thu, 26 Mar 2026 08:40:12 +0900
Subject: [PATCH v2] Restore tgdeferrable and tginitdeferred after NOT ENFORCED
then ENFORCED
When toggling a foreign key constraint from NOT ENFORCED to ENFORCED,
the deferrable and initdeferred flags were not copied from the existing
constraint to the new trigger structure, causing them to be lost.
Message-Id: CAKmOUTms2nkxEZDdcrsjq5P3b2L_PR266Hv8kW5pANwmVaRJJQ@mail.gmail.com
---
src/backend/commands/tablecmds.c | 2 +
src/test/regress/expected/foreign_key.out | 58 +++++++++++++++++++++++
src/test/regress/sql/foreign_key.sql | 36 ++++++++++++++
3 files changed, 96 insertions(+)
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index c69c12dc014..dd00e36c69d 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -12558,6 +12558,8 @@ ATExecAlterFKConstrEnforceability(List **wqueue, ATAlterConstraint *cmdcon,
fkconstraint->fk_matchtype = currcon->confmatchtype;
fkconstraint->fk_upd_action = currcon->confupdtype;
fkconstraint->fk_del_action = currcon->confdeltype;
+ fkconstraint->deferrable = currcon->condeferrable;
+ fkconstraint->initdeferred = currcon->condeferred;
/* Create referenced triggers */
if (currcon->conrelid == fkrelid)
diff --git a/src/test/regress/expected/foreign_key.out b/src/test/regress/expected/foreign_key.out
index 9ae4dbf1b0a..4ab8ed63ff4 100644
--- a/src/test/regress/expected/foreign_key.out
+++ b/src/test/regress/expected/foreign_key.out
@@ -1349,6 +1349,64 @@ UPDATE pktable SET id = 10 WHERE id = 5;
-- doesn't match PK, but no error.
INSERT INTO fktable VALUES (0, 20);
ROLLBACK;
+-- verify that tgdeferrable/tginitdeferred are preserved after NOT ENFORCED -> ENFORCED
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey DEFERRABLE INITIALLY DEFERRED;
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey NOT ENFORCED;
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey ENFORCED;
+SELECT tgdeferrable, tginitdeferred FROM pg_trigger
+WHERE tgconstraint = (SELECT oid FROM pg_constraint
+ WHERE conrelid = 'fktable'::regclass
+ AND conname = 'fktable_fk_fkey');
+ tgdeferrable | tginitdeferred
+--------------+----------------
+ t | t
+ t | t
+ t | t
+ t | t
+(4 rows)
+
+-- verify actual behavior: violation should be deferred to end of transaction
+BEGIN;
+-- doesn't match PK, but no error yet (INITIALLY DEFERRED)
+INSERT INTO fktable VALUES (2, 20);
+-- should catch error from INSERT at commit
+COMMIT;
+ERROR: insert or update on table "fktable" violates foreign key constraint "fktable_fk_fkey"
+DETAIL: Key (fk)=(20) is not present in table "pktable".
+-- reset
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey NOT DEFERRABLE;
+-- same, but with DEFERRABLE INITIALLY IMMEDIATE: tginitdeferred should be false
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey DEFERRABLE INITIALLY IMMEDIATE;
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey NOT ENFORCED;
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey ENFORCED;
+SELECT tgdeferrable, tginitdeferred FROM pg_trigger
+WHERE tgconstraint = (SELECT oid FROM pg_constraint
+ WHERE conrelid = 'fktable'::regclass
+ AND conname = 'fktable_fk_fkey');
+ tgdeferrable | tginitdeferred
+--------------+----------------
+ t | f
+ t | f
+ t | f
+ t | f
+(4 rows)
+
+-- verify actual behavior: violation should be caught immediately (INITIALLY IMMEDIATE)
+-- doesn't match PK, error at INSERT time
+INSERT INTO fktable VALUES (2, 20);
+ERROR: insert or update on table "fktable" violates foreign key constraint "fktable_fk_fkey"
+DETAIL: Key (fk)=(20) is not present in table "pktable".
+-- verify that SET CONSTRAINTS DEFERRED still works
+BEGIN;
+SET CONSTRAINTS fktable_fk_fkey DEFERRED;
+-- doesn't match PK, but no error yet (explicitly deferred)
+INSERT INTO fktable VALUES (2, 20);
+-- should catch error from INSERT at commit
+COMMIT;
+ERROR: insert or update on table "fktable" violates foreign key constraint "fktable_fk_fkey"
+DETAIL: Key (fk)=(20) is not present in table "pktable".
+-- reset
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey NOT DEFERRABLE;
-- try additional syntax
ALTER TABLE fktable ALTER CONSTRAINT fktable_fk_fkey NOT DEFERRABLE;
-- illegal options
diff --git a/src/test/regress/sql/foreign_key.sql b/src/test/regress/sql/foreign_key.sql
index 3b8c95bf893..d5d6b9a8cef 100644
--- a/src/test/regress/sql/foreign_key.sql
+++ b/src/test/regress/sql/foreign_key.sql
@@ -1023,6 +1023,42 @@ UPDATE pktable SET id = 10 WHERE id = 5;
INSERT INTO fktable VALUES (0, 20);
ROLLBACK;
+-- verify that tgdeferrable/tginitdeferred are preserved after NOT ENFORCED -> ENFORCED
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey DEFERRABLE INITIALLY DEFERRED;
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey NOT ENFORCED;
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey ENFORCED;
+SELECT tgdeferrable, tginitdeferred FROM pg_trigger
+WHERE tgconstraint = (SELECT oid FROM pg_constraint
+ WHERE conrelid = 'fktable'::regclass
+ AND conname = 'fktable_fk_fkey');
+-- verify actual behavior: violation should be deferred to end of transaction
+BEGIN;
+-- doesn't match PK, but no error yet (INITIALLY DEFERRED)
+INSERT INTO fktable VALUES (2, 20);
+-- should catch error from INSERT at commit
+COMMIT;
+-- reset
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey NOT DEFERRABLE;
+-- same, but with DEFERRABLE INITIALLY IMMEDIATE: tginitdeferred should be false
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey DEFERRABLE INITIALLY IMMEDIATE;
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey NOT ENFORCED;
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey ENFORCED;
+SELECT tgdeferrable, tginitdeferred FROM pg_trigger
+WHERE tgconstraint = (SELECT oid FROM pg_constraint
+ WHERE conrelid = 'fktable'::regclass
+ AND conname = 'fktable_fk_fkey');
+-- verify actual behavior: violation should be caught immediately (INITIALLY IMMEDIATE)
+-- doesn't match PK, error at INSERT time
+INSERT INTO fktable VALUES (2, 20);
+-- verify that SET CONSTRAINTS DEFERRED still works
+BEGIN;
+SET CONSTRAINTS fktable_fk_fkey DEFERRED;
+-- doesn't match PK, but no error yet (explicitly deferred)
+INSERT INTO fktable VALUES (2, 20);
+-- should catch error from INSERT at commit
+COMMIT;
+-- reset
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey NOT DEFERRABLE;
-- try additional syntax
ALTER TABLE fktable ALTER CONSTRAINT fktable_fk_fkey NOT DEFERRABLE;
--
2.53.0
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED
2026-02-27 09:51 [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Yasuo Honda <[email protected]>
2026-03-24 06:29 ` Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Fujii Masao <[email protected]>
2026-03-27 07:41 ` Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Yasuo Honda <[email protected]>
@ 2026-03-27 15:01 ` Fujii Masao <[email protected]>
2026-03-30 05:40 ` Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Fujii Masao <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Fujii Masao @ 2026-03-27 15:01 UTC (permalink / raw)
To: Yasuo Honda <[email protected]>; +Cc: pgsql-hackers
On Fri, Mar 27, 2026 at 4:41 PM Yasuo Honda <[email protected]> wrote:
>
> (Resending to the list, as my previous reply went to the sender only.)
>
> Thanks for the comment.
>
> > Regarding the regression test, would it be better to verify not only catalog
> state (e.g., pg_trigger) but also the actual behavior?
>
> Agreed. In addition to inspecting pg_trigger contents, I've added test
> cases that verify the actual runtime behavior of deferred constraints.
Thanks for updating the patch!
> I've also covered INITIALLY IMMEDIATE alongside INITIALLY DEFERRED.
I'm not sure this test adds much value. Testing DEFERRABLE INITIALLY DEFERRED
seems sufficient, so I removed the DEFERRABLE INITIALLY IMMEDIATE case.
The updated patch is attached.
+-- verify that tgdeferrable/tginitdeferred are preserved after NOT
ENFORCED -> ENFORCED
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey DEFERRABLE
INITIALLY DEFERRED;
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey NOT ENFORCED;
It looks like this assumes the constraint is initially ENFORCED,
but in this part of the test it is already NOT ENFORCED. So I moved
this test to a section where the constraint is ENFORCED, which
seems more appropriate.
I also updated the commit log message.
Barring any objections, I will commit this and backpatch it to v18, where
NOT ENFORCED foreign keys were introduced.
Regards,
--
Fujii Masao
Attachments:
[application/octet-stream] v3-0001-Fix-FK-triggers-losing-DEFERRABLE-INITIALLY-DEFER.patch (7.4K, 2-v3-0001-Fix-FK-triggers-losing-DEFERRABLE-INITIALLY-DEFER.patch)
download | inline diff:
From b15a5183bc99a1985ae5899c5e5aa7257c602f4c Mon Sep 17 00:00:00 2001
From: Fujii Masao <[email protected]>
Date: Fri, 27 Mar 2026 18:29:07 +0900
Subject: [PATCH v3] Fix FK triggers losing DEFERRABLE/INITIALLY DEFERRED when
marked ENFORCED again
Previously, a foreign key defined as DEFERRABLE INITIALLY DEFERRED could
behave as NOT DEFERRABLE after being set to NOT ENFORCED and then back
to ENFORCED.
This happened because recreating the FK triggers on re-enabling the constraint
forgot to restore the tgdeferrable and tginitdeferred fields in pg_trigger.
Fix this bug by properly setting those fields when the foreign key constraint
is marked ENFORCED again and its triggers are recreated, so the original
DEFERRABLE and INITIALLY DEFERRED properties are preserved.
Backpatch to v18, where NOT ENFORCED foreign keys were introduced.
Author: Yasuo Honda <[email protected]>
Reviewed-by: Fujii Masao <[email protected]>
Discussion: https://postgr.es/m/CAKmOUTms2nkxEZDdcrsjq5P3b2L_PR266Hv8kW5pANwmVaRJJQ@mail.gmail.com
Backpatch-through: 18
---
src/backend/commands/tablecmds.c | 2 +
src/test/regress/expected/foreign_key.out | 53 +++++++++++++++++++++++
src/test/regress/sql/foreign_key.sql | 37 ++++++++++++++++
3 files changed, 92 insertions(+)
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index c69c12dc014..dd00e36c69d 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -12558,6 +12558,8 @@ ATExecAlterFKConstrEnforceability(List **wqueue, ATAlterConstraint *cmdcon,
fkconstraint->fk_matchtype = currcon->confmatchtype;
fkconstraint->fk_upd_action = currcon->confupdtype;
fkconstraint->fk_del_action = currcon->confdeltype;
+ fkconstraint->deferrable = currcon->condeferrable;
+ fkconstraint->initdeferred = currcon->condeferred;
/* Create referenced triggers */
if (currcon->conrelid == fkrelid)
diff --git a/src/test/regress/expected/foreign_key.out b/src/test/regress/expected/foreign_key.out
index 9ae4dbf1b0a..4c69cb999cd 100644
--- a/src/test/regress/expected/foreign_key.out
+++ b/src/test/regress/expected/foreign_key.out
@@ -1157,6 +1157,59 @@ INSERT INTO fktable VALUES (500, 1000);
ERROR: insert or update on table "fktable" violates foreign key constraint "fktable_fk_fkey"
DETAIL: Key (fk)=(1000) is not present in table "pktable".
COMMIT;
+-- Check that the existing FK trigger is both deferrable and initially deferred
+SELECT conname, tgrelid::regclass as tgrel,
+ regexp_replace(tgname, '[0-9]+', 'N') as tgname, tgtype,
+ tgdeferrable, tginitdeferred
+FROM pg_trigger t JOIN pg_constraint c ON (t.tgconstraint = c.oid)
+WHERE conrelid = 'fktable'::regclass AND conname = 'fktable_fk_fkey'
+ORDER BY tgrelid, tgtype;
+ conname | tgrel | tgname | tgtype | tgdeferrable | tginitdeferred
+-----------------+---------+--------------------------+--------+--------------+----------------
+ fktable_fk_fkey | pktable | RI_ConstraintTrigger_a_N | 9 | t | t
+ fktable_fk_fkey | pktable | RI_ConstraintTrigger_a_N | 17 | t | t
+ fktable_fk_fkey | fktable | RI_ConstraintTrigger_c_N | 5 | t | t
+ fktable_fk_fkey | fktable | RI_ConstraintTrigger_c_N | 17 | t | t
+(4 rows)
+
+-- Changing the constraint to NOT ENFORCED drops the associated FK triggers
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey NOT ENFORCED;
+SELECT conname, tgrelid::regclass as tgrel,
+ regexp_replace(tgname, '[0-9]+', 'N') as tgname, tgtype,
+ tgdeferrable, tginitdeferred
+FROM pg_trigger t JOIN pg_constraint c ON (t.tgconstraint = c.oid)
+WHERE conrelid = 'fktable'::regclass AND conname = 'fktable_fk_fkey'
+ORDER BY tgrelid, tgtype;
+ conname | tgrel | tgname | tgtype | tgdeferrable | tginitdeferred
+---------+-------+--------+--------+--------------+----------------
+(0 rows)
+
+-- Changing it back to ENFORCED will recreate the necessary FK triggers
+-- that are deferrable and initially deferred
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey ENFORCED;
+SELECT conname, tgrelid::regclass as tgrel,
+ regexp_replace(tgname, '[0-9]+', 'N') as tgname, tgtype,
+ tgdeferrable, tginitdeferred
+FROM pg_trigger t JOIN pg_constraint c ON (t.tgconstraint = c.oid)
+WHERE conrelid = 'fktable'::regclass AND conname = 'fktable_fk_fkey'
+ORDER BY tgrelid, tgtype;
+ conname | tgrel | tgname | tgtype | tgdeferrable | tginitdeferred
+-----------------+---------+--------------------------+--------+--------------+----------------
+ fktable_fk_fkey | pktable | RI_ConstraintTrigger_a_N | 9 | t | t
+ fktable_fk_fkey | pktable | RI_ConstraintTrigger_a_N | 17 | t | t
+ fktable_fk_fkey | fktable | RI_ConstraintTrigger_c_N | 5 | t | t
+ fktable_fk_fkey | fktable | RI_ConstraintTrigger_c_N | 17 | t | t
+(4 rows)
+
+-- Verify that a deferrable, initially deferred foreign key still works
+-- as expected after being set to NOT ENFORCED and then re-enabled
+BEGIN;
+-- doesn't match PK, but no error yet
+INSERT INTO fktable VALUES (2, 20);
+-- should catch error from INSERT at commit
+COMMIT;
+ERROR: insert or update on table "fktable" violates foreign key constraint "fktable_fk_fkey"
+DETAIL: Key (fk)=(20) is not present in table "pktable".
DROP TABLE fktable, pktable;
-- tricky behavior: according to SQL99, if a deferred constraint is set
-- to 'immediate' mode, it should be checked for validity *immediately*,
diff --git a/src/test/regress/sql/foreign_key.sql b/src/test/regress/sql/foreign_key.sql
index 3b8c95bf893..02a60d661a1 100644
--- a/src/test/regress/sql/foreign_key.sql
+++ b/src/test/regress/sql/foreign_key.sql
@@ -784,6 +784,43 @@ INSERT INTO fktable VALUES (500, 1000);
COMMIT;
+-- Check that the existing FK trigger is both deferrable and initially deferred
+SELECT conname, tgrelid::regclass as tgrel,
+ regexp_replace(tgname, '[0-9]+', 'N') as tgname, tgtype,
+ tgdeferrable, tginitdeferred
+FROM pg_trigger t JOIN pg_constraint c ON (t.tgconstraint = c.oid)
+WHERE conrelid = 'fktable'::regclass AND conname = 'fktable_fk_fkey'
+ORDER BY tgrelid, tgtype;
+
+-- Changing the constraint to NOT ENFORCED drops the associated FK triggers
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey NOT ENFORCED;
+SELECT conname, tgrelid::regclass as tgrel,
+ regexp_replace(tgname, '[0-9]+', 'N') as tgname, tgtype,
+ tgdeferrable, tginitdeferred
+FROM pg_trigger t JOIN pg_constraint c ON (t.tgconstraint = c.oid)
+WHERE conrelid = 'fktable'::regclass AND conname = 'fktable_fk_fkey'
+ORDER BY tgrelid, tgtype;
+
+-- Changing it back to ENFORCED will recreate the necessary FK triggers
+-- that are deferrable and initially deferred
+ALTER TABLE FKTABLE ALTER CONSTRAINT fktable_fk_fkey ENFORCED;
+SELECT conname, tgrelid::regclass as tgrel,
+ regexp_replace(tgname, '[0-9]+', 'N') as tgname, tgtype,
+ tgdeferrable, tginitdeferred
+FROM pg_trigger t JOIN pg_constraint c ON (t.tgconstraint = c.oid)
+WHERE conrelid = 'fktable'::regclass AND conname = 'fktable_fk_fkey'
+ORDER BY tgrelid, tgtype;
+
+-- Verify that a deferrable, initially deferred foreign key still works
+-- as expected after being set to NOT ENFORCED and then re-enabled
+BEGIN;
+
+-- doesn't match PK, but no error yet
+INSERT INTO fktable VALUES (2, 20);
+
+-- should catch error from INSERT at commit
+COMMIT;
+
DROP TABLE fktable, pktable;
-- tricky behavior: according to SQL99, if a deferred constraint is set
--
2.51.2
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED
2026-02-27 09:51 [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Yasuo Honda <[email protected]>
2026-03-24 06:29 ` Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Fujii Masao <[email protected]>
2026-03-27 07:41 ` Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Yasuo Honda <[email protected]>
2026-03-27 15:01 ` Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Fujii Masao <[email protected]>
@ 2026-03-30 05:40 ` Fujii Masao <[email protected]>
2026-03-30 12:17 ` Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Yasuo Honda <[email protected]>
0 siblings, 1 reply; 6+ messages in thread
From: Fujii Masao @ 2026-03-30 05:40 UTC (permalink / raw)
To: Yasuo Honda <[email protected]>; +Cc: pgsql-hackers
On Sat, Mar 28, 2026 at 12:01 AM Fujii Masao <[email protected]> wrote:
> Barring any objections, I will commit this and backpatch it to v18, where
> NOT ENFORCED foreign keys were introduced.
I've pushed the patch. Thanks!
Regards,
--
Fujii Masao
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED
2026-02-27 09:51 [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Yasuo Honda <[email protected]>
2026-03-24 06:29 ` Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Fujii Masao <[email protected]>
2026-03-27 07:41 ` Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Yasuo Honda <[email protected]>
2026-03-27 15:01 ` Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Fujii Masao <[email protected]>
2026-03-30 05:40 ` Re: [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Fujii Masao <[email protected]>
@ 2026-03-30 12:17 ` Yasuo Honda <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Yasuo Honda @ 2026-03-30 12:17 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: pgsql-hackers
> I've pushed the patch. Thanks!
Thanks for reviewing and committing this, and for the fixups.
Once this fix is released, I can complete NOT ENFORCED foreign key
support in Ruby on Rails.
--
Yasuo Honda
On Mon, Mar 30, 2026 at 2:41 PM Fujii Masao <[email protected]> wrote:
>
> On Sat, Mar 28, 2026 at 12:01 AM Fujii Masao <[email protected]> wrote:
> > Barring any objections, I will commit this and backpatch it to v18, where
> > NOT ENFORCED foreign keys were introduced.
>
> I've pushed the patch. Thanks!
>
> Regards,
>
> --
> Fujii Masao
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-03-30 12:17 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-02-27 09:51 [PATCH] Fix unexpected loss of DEFERRABLE property after toggling NOT ENFORCED / ENFORCED Yasuo Honda <[email protected]>
2026-03-24 06:29 ` Fujii Masao <[email protected]>
2026-03-27 07:41 ` Yasuo Honda <[email protected]>
2026-03-27 15:01 ` Fujii Masao <[email protected]>
2026-03-30 05:40 ` Fujii Masao <[email protected]>
2026-03-30 12:17 ` Yasuo Honda <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox