[TheSentinel454]

Stack (merge bottom-up): main ← #8325 ← #8326 (0087) ← #8323 (0088) ← #8211 (0089). Migrations are pre-numbered in stack order, so each PR's migration.rs count assumes the ones below it.

Deploy gate (ops, not CI): merge only after #8219, #8318 and #8322 are deployed on every pod, with no rollback below them expected. No tagged relay release contains the fence (it arrived in 0029, after relay-v0.2.1), so there is no release to name as the required stop. The minimum image is any main build at or after 60de1db0b (#8318's merge, which already contains #8219 and #8322). Merging also needs Luke's explicit merge/DDL approval; review readiness is not rollout approval. Relay pods auto-migrate at boot, so the gate has to hold before this rolling deploy starts. Starting it is already too late.

Rollout note: 0088 takes AccessExclusive on each of the 33 tables (including events) and holds every lock until commit. While it waits up to 5s (lock_timeout) on one table, the tables it has already locked stay blocked for reads as well as writes, so serving traffic can stall table by table. If a wait times out, db.migrate() fails and the pod crashloops under BUZZ_AUTO_MIGRATE until 0088 gets through. Apply 0088 in a low-write window, or from a single migrator pod before the rollout, rather than letting every new pod race for it.

Out-of-band pgschema apply: apply 0088 first, or drop community_write_fence_events and community_write_fence_delivery_log (the two partitioned parents) first. The same applies to events_created_at_floor before #8326's 0087. Otherwise pgschema plans the partition-clone drops before the parent drop, and Postgres refuses with 2BP01. The upgrade fixture pre-drops all three for this reason.

What

This is the contract step for BUZZ-315. Migration 0088_retire_community_write_fence.sql:

• starts with SET LOCAL lock_timeout = '5s', the convention in 0029/0030/0051/0053/0054 (the migrator otherwise runs with lock_timeout = 0). An unbounded AccessExclusive wait across events and 31 other hot tables would queue serving traffic behind it. A timeout aborts the transactional migration, and the pod retries on its next boot.
• drops the 33 parent community_write_fence_* triggers. Partition clones go with them.
• drops the five fence-only functions without CASCADE: enforce_community_write_fence, attach_community_write_fence, community_write_fence_excluded_table, community_write_allowed and assert_community_write_allowed.

The desired state follows:

• schema/schema.sql and the trigger attachments in channels.sql/events.sql are updated.
• 30 trigger files that held only a fence attachment are deleted, along with the five function files and schema/community_write_fence.sql.
• Partition-fence reconciliation is removed from scripts/reconcile-schema-after-pgschema.sql.

Both boot paths, desired-template and run_migrations, end with zero universal fences.

New inventories leave the legacy fenced_tables snapshot empty. #8322's executor ignores it, and the field remains so existing frozen digests stay valid. The live-fence catalog reader is deleted. The transitional exclusion-parity test read community_write_fence_excluded_table.sql via include_str!, which this PR deletes; excluded_scoped_tables_are_live_control_plane_tables replaces it. It pins EXCLUDED_SCOPED_TABLES to a control-plane list written out in the test (not derived from EXPECTED_SCOPED_TABLES), requires every excluded table to still exist with a community_id, and requires the live provenance tables to be exactly tenant ∪ control-plane, so moving a tenant table into the exclusion list fails.

Kept:

• community_deletion_lock_key: app admission, deletion code, relay lock tests and the bridge mini-schemas still call it.
• enforce_community_tombstone / communities_deletion_tombstone: independent of the dropped functions; BUZZ-318 owns them.

Writer inventory: 189 DML sites across crates/ and scripts/ on the 32 tables. Every serving writer goes through AdmittedTx/begin_community_*_write_transaction, guard_transaction, the deletion executor under its generation GUC, or a rolled-back startup probe. The exceptions are #8318's seven statements. Direct maintenance scripts lose the trigger backstop and stay outside the supported-writer contract.

Mixed versions (rollout of this PR)

Combination	Why it is safe
Pod at #8322 + #8318, DB after 0088	Startup and readiness, scoped-table discovery and lease admission no longer touch the dropped objects. #8318 removed the seven in-SQL predicates.
Pod at this commit, DB before 0088	Validators accept either catalog (migrated_catalog_retires_universal_fences_but_keeps_deletion_guards checks startup before the retirement migration, then after it).
#8322 executor, inventory frozen here (empty fences)	#8322 ignores the fence list.

Not safe: a pod at #8322 without #8318 on a DB after 0088. Serving and deletion keep working, but the push matcher, exhausted-job reaper, invite retention sweep, ephemeral channel reaper and startup d_tag backfill fail with 42883 community_write_allowed(uuid) does not exist (observed in deploy-stack E2E). Rollback images after 0088 must include #8318, and no image older than #8219 + #8318 + #8322 may run against a post-0088 DB.

Tests

• runtime::migration::postgres_tests::migrated_catalog_retires_universal_fences_but_keeps_deletion_guards
• store::deletion::postgres_tests::desired_state_catalog_has_no_universal_fence_and_still_boots
• The 0088 source assertions in embedded_migrator_contains_consolidated_initial_schema. They pin all 33 drops, the five functions, the retained lock key and tombstone, and the leading lock_timeout.
• Trigger-only assertions are removed, and the open-write deletion-ordering test now uses an admitted write.

Each test was confirmed to fail when its fix is removed (rc 100, 0/1):

• with SET LOCAL removed, the source assertion fails;
• with 0088 dropped from the migrator, the fence triggers remain (parents plus partition clones);
• with the old desired schema and reconcile script restored, 46 fence triggers remain.

Test-fixture changes:

• push.rs loses two cleanup DELETEs that called the dropped function. Per-test databases make them redundant.
• The 0049 thread-window test releases its held writer before running the full migrator, because 0088's DROP TRIGGER correctly waits on that writer's lock.

What got simpler

33 triggers, 5 SQL functions, 37 schema files and the live-fence catalog reader are deleted, along with their boot/catalog probes. The diff over the stack base is 275 insertions and 607 deletions.

Identified debt (pre-existing, outside this diff): writer_pool_rejects_non_read_committed_database_default and writer_pool_metrics_stop_after_session_timeout_setup_failure hang on clean 177551dda.

Verification

Head a79e49857, restacked onto #8326, plus the upgrade-fixture fix from review (pre-drops of the two fence parents and the floor trigger) and removal of fence_waits_for_open_write_and_rejects_it_after_transition. With the trigger gone, its wait came from the pubkey_allowlist FK, not the deletion lock; begin_quiescing_waits_for_open_admitted_writer_note_update and community_fence_rejects_fresh_begin_transaction_after_fence cover both halves. CI skips the PostgreSQL job on stacked PRs, so the buzz-db PG lane runs on Blox; it is running at this head.

Migration numbering: 0088, after #8326's 0087; #8211 takes 0089 on top.

[loganj]

🤖 Larry and Auto: an independent adversarial review of fd5d9f5dd1. Source review only, plus local Postgres 17 runs and mutation tests. Most of the review was done at c910fbde55. The restack onto #8326 changes only the migration number (0087 to 0088; the SQL is byte-identical), ARCHITECTURE.md and schema/triggers/events.sql, and we checked that delta.

Approving. The production change is sound. One test at this head fails, and it shows a real ordering problem on the pgschema deployment path.

Must-fix (error): migration_schema_desired_pgschema_reconcile_matches_populated_upgrade fails.

• At relay_invite/upgrade_postgres_tests.rs:496, pgschema stops with cannot drop trigger community_write_fence_events on table events_p2026_04 because trigger community_write_fence_events on table events requires it (SQLSTATE 2BP01). pgschema plans the partition-clone drops before the parent drop.
• It passes on main and fails here, both at c910fbde55 and at fd5d9f5dd1, and it fails the same way when run alone.
• Fix (test): the fixture's pre-drop list at :428-440 already handles this for the earlier retired events triggers. Add DROP TRIGGER IF EXISTS community_write_fence_events ON events; and DROP TRIGGER IF EXISTS community_write_fence_delivery_log ON delivery_log; to it.
• Ops consequence: an out-of-band pgschema apply of the new desired state onto a database that has not run 0088 fails the same way. Please add one line to the rollout notes: run 0088 first, or drop those two parent triggers before the apply.

Fixed by the restack: media_edit_index_upgrade_builds_inline_or_verifies_prebuild timed out (55P03) at the retirement migration at c910fbde55, because it held ROW EXCLUSIVE on events through the full migrator. At fd5d9f5dd1 it passes, because #8326's base now stops the held-writer part at 0086. Any later PR that drops something on events must keep that order.

What we checked

• Every serving writer is still admitted in the app. Auto went through 174 production DML sites on the 33 tables, and checked the 29 that a keyword scan could not place by hand. Each one goes through AdmittedTx, guard_transaction, sweep_admitted_communities, the deletion executor, or a raw-connection helper whose every caller passes an admitted transaction. We found no unadmitted writer.
• The drop list is complete. The 33 drops match every desired-state attachment. product_feedback and rate_limit_violations were already dropped in 0030. No production SQL calls the dropped functions, here or at main.
• Rollout: #8219, #8318 and #8322 are on main, so this is a proper contract step. No tagged relay release ever contained the fence (it arrived in 0029, after relay-v0.2.1), so only untagged main builds older than #8318/#8322 are exposed. The body's image gate is the right control.
• Mutations, all caught: dropping guard_transaction from push enqueue; admitting quiescing in guard_community_write; the NIP-FI bind without deletion_state='active'; hiding channels in EXCLUDED_SCOPED_TABLES; 0088 skipping the users drop. One survives, in a test (see the inline comment).

Should-fix: docs/database.md's "retire a trigger" step 2 asks for release notes that name the step-1 release as a required stop. There is no such relay release. Say so in the body, and name the minimum image instead.

Optional

• The source policy that forces writers through admission (GUARDED_TABLE_WRITE_MARKERS, tests/observability_source.rs:838) covers only events, reactions and event_mentions. With the trigger gone, nothing static stops a new raw writer on the other 30 tables, but docs/database.md now says every serving writer goes through admission. You could derive the markers from EXPECTED_SCOPED_TABLES, and move the raw-connection helpers to &mut AdmittedTx or pin them.
• scripts/backfill-d-tag.sql runs a fleet-wide UPDATE events with no deletion lock. The trigger used to make it fail on a quiescing community; now it writes through. Retire it, or make it take the lock.
• Lock window: the migration holds ACCESS EXCLUSIVE on all 33 tables and every partition until commit, and waits up to 5 s for each. The body's single-migrator, low-write-window advice covers this. A shorter lock_timeout, or locking the hottest tables first, would shorten the worst case.
• Two test helpers no longer have anything to do: test_support::reject_legacy_sql_fence_predicate (:231, 9 callers) and session_replication_role = replica in admission_fixture.
• The body is stale: 0066 (now 0088), "32" triggers (33), "main is at 0064", "Pending at 525bc80a", and the numbering paragraph.

[loganj]

🤖 Must-fix (error), test and ops note. pgschema cannot reproduce this drop on a populated database. It plans DROP TRIGGER community_write_fence_events ON events_p2026_* before the parent drop, and Postgres refuses with 2BP01, because the clones belong to the parent trigger. This makes migration_schema_desired_pgschema_reconcile_matches_populated_upgrade fail (relay_invite/upgrade_postgres_tests.rs:496). The same goes for community_write_fence_delivery_log (:15).

Fix: add both parent drops to the fixture's pre-drop list (upgrade_postgres_tests.rs:428-440). Also note in the rollout section that an out-of-band apply needs 0088 to run first, or these two parent triggers dropped first.

[loganj]

🤖 Optional (test validity). fence_waits_for_open_write_and_rejects_it_after_transition no longer tests the deletion lock. The wait it sees comes from the foreign key: the pubkey_allowlist insert takes KEY SHARE on communities, and the FOR UPDATE in begin_quiescing waits on that. Without the trigger, a write that lands after the fence also succeeds. Auto moved the shared deletion lock to the wrong key, and this test still passed; begin_quiescing_waits_for_open_admitted_writer_note_update caught it. Fix: use a table with no FK to communities, or assert the advisory-lock wait in pg_locks, or delete this test because :7394 covers it.