From 61ead0c2b8343c6593abc1a27b9be32307b9f64b Mon Sep 17 00:00:00 2001 From: Kiran Muddukrishna Date: Sat, 24 Oct 2026 09:48:59 -0700 Subject: [PATCH 1/2] replay: pin buzz's unnamed ADD FOREIGN KEY as executed The planner now names an unnamed constraint so its NOT VALID + VALIDATE sequence can run, so the pinned refusal no longer matches and make replay fails on main. --- replay/buzz/README.md | 6 +++--- replay/buzz/assessment.tsv | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/replay/buzz/README.md b/replay/buzz/README.md index f8202791..70e95426 100644 --- a/replay/buzz/README.md +++ b/replay/buzz/README.md @@ -26,6 +26,6 @@ behaviors worth knowing when reading the results: - `CREATE INDEX IF NOT EXISTS` is refused by design — a name-only no-op cannot prove the existing index is valid or even the requested one. -- Buzz's unnamed `ADD FOREIGN KEY` is refused (`not-native-safe-rewrite-required`) - while the same constraint written with `CONSTRAINT ` executes via the safer - `NOT VALID` + `VALIDATE` sequence — the rewrite needs a name to reference. +- Buzz's unnamed `ADD FOREIGN KEY` executes via the safer `NOT VALID` + `VALIDATE` + sequence: the `VALIDATE` step has to name the constraint, so pg-sprite states the + name PostgreSQL would choose (`__fkey`). diff --git a/replay/buzz/assessment.tsv b/replay/buzz/assessment.tsv index e9526dfa..b7a12efe 100644 --- a/replay/buzz/assessment.tsv +++ b/replay/buzz/assessment.tsv @@ -39,9 +39,9 @@ 0006 94-118 refuse:unsupported-statement:no-online-safety-problem:declarative-front-door 0006 120-121 execute 0006 122-124 execute -# Unnamed ADD FOREIGN KEY: the safer NOT VALID + VALIDATE sequence needs a -# constraint name to reference; the same constraint with CONSTRAINT executes. -0006 128-130 refuse:not-native-safe-rewrite-required:capability-boundary +# Unnamed ADD FOREIGN KEY: executes as NOT VALID + VALIDATE under the name +# PostgreSQL would choose (moderation_reports_community_id_action_id_fkey). +0006 128-130 execute 0007 12-12 psql 0007 14-22 refuse:unsupported-statement:no-online-safety-problem:declarative-front-door 0007 26-27 execute From 5867dfb948f84d26bcdc3f3f10daf9feee538eab Mon Sep 17 00:00:00 2001 From: Kiran Muddukrishna Date: Fri, 30 Oct 2026 11:34:27 +1100 Subject: [PATCH 2/2] replay: say the fkey name follows the server's truncation and numbering --- replay/buzz/README.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/replay/buzz/README.md b/replay/buzz/README.md index 42f67537..421ee6c4 100644 --- a/replay/buzz/README.md +++ b/replay/buzz/README.md @@ -28,7 +28,9 @@ behaviors worth knowing when reading the results: the existing index is valid or even the requested one. - Buzz's unnamed `ADD FOREIGN KEY` executes via the safer `NOT VALID` + `VALIDATE` sequence: the `VALIDATE` step has to name the constraint, so pg-sprite states the - name PostgreSQL would choose (`
__fkey`). + name PostgreSQL would choose — `
__fkey`, truncated to the identifier + limit and numbered past a name already taken, as the server does. Here that is + `moderation_reports_community_id_action_id_fkey`. - Every `DROP COLUMN`, `DROP CONSTRAINT`, and `DROP NOT NULL` is refused by design (`destructive-change`): the replay never passes `--allow-destructive`, so it pins the refusal and advances the history through psql.