Install mesh_node_notify per TABLE, not once per database (V54) by rbuergi · Pull Request #1816 · Systemorph/MeshWeaver

rbuergi · 2026-08-17T22:45:15Z

Measured first

On a live 33-partition database, before any change:

trigger	present	missing
`mesh_node_notify` on `mesh_nodes`	1	32
`*_notify` on satellite tables	231	0
`mesh_node_copy_to_history`	33	0

The one schema carrying mesh_node_notify is public — which AGENTS.md documents as empty by design. So in practice no node write in that database had ever emitted pg_notify.

Root cause

Three schema scripts created the trigger like this:

IF NOT EXISTS (SELECT 1 FROM pg_trigger WHERE tgname = 'mesh_node_notify')

pg_trigger is a database-global catalog; trigger names are unique per table. The first schema provisioned therefore satisfied the predicate for the entire database, and every schema created afterwards silently skipped installing its own. Nothing failed — each schema concluded the work was already done, because somewhere else it was.

This is the identical defect V44 repaired for the sibling trigger mesh_node_copy_to_history — in one of the same methods (GetVersionedPartitionDdl). That repair fixed one trigger and left its neighbour.

Why it stayed hidden

Two independent reasons, which is why it lasted:

Satellites were never affected. GetSatelliteTableScript always used the per-table form, so a partition's _Access / _Thread / _Activity writes notified while that same partition's mesh_nodes writes did not. The asymmetry makes the symptom look selective rather than systemic.
The in-process IStorageAdapter.Changes feed still carries same-process writes, so only a notification that had to cross a process boundary was lost — and it was lost silently, with the write reporting success.

The fix, both halves

Source: the three scripts now use the per-table DROP TRIGGER IF EXISTS … ON <table>; CREATE TRIGGER … form that the other ~20 triggers in the file already use. New schemas are correct by construction.
V54: installs the trigger on existing schemas that lack it. It touches only schemas genuinely missing it — CREATE/DROP TRIGGER takes an ACCESS EXCLUSIVE lock and this loop runs over every partition on the server, so re-applying an identical definition would buy nothing and cost a lock per partition. It reports how many were missing, not merely that it finished.

mesh_node_copy_to_history gets no data repair — measured 33/33 already present, because V44 covered every existing schema. Its source-side guard in GetMeshSchemaScript is fixed alongside so a new schema cannot regress.

🚨 The third site was found by the test, not by eye

The test rejects the shape — any trigger created under a guard that checks only a name without constraining the table — rather than this one trigger. On its first run it immediately flagged a live instance I had not fixed: mesh_node_copy_to_history in GetMeshSchemaScript, still on the global guard. A targeted fix would have shipped that regression forward into every newly created schema.

It also carries a negative control (the real guard must still be flagged) and its complement (a properly table-scoped probe must still be allowed), so it forbids the defect rather than the catalog and cannot quietly become vacuous. WithoutComments exists because the scripts document this anti-pattern in their own comments — the first run flagged that prose, which is itself evidence the scanner reads what it claims to.

Verification

dotnet build -c Release -warnaserror clean: MeshWeaver.Hosting.PostgreSql, Memex.Database.Migration, MeshWeaver.Documentation.
Passed! - Failed: 0, Passed: 9.
DbVersion.Latest 53 → 54, registered in MigrationRegistry.

🤖 Generated with Claude Code

MEASURED on a live 33-partition database: `mesh_node_notify` was present on exactly ONE schema's mesh_nodes and missing from 32. The one schema that had it is `public` — which is empty by design — so no node write in that database had ever emitted pg_notify. Root cause, in three schema scripts: IF NOT EXISTS (SELECT 1 FROM pg_trigger WHERE tgname = 'mesh_node_notify') `pg_trigger` is a database-global catalog; trigger names are unique per TABLE. So the first schema provisioned satisfied the predicate for the whole database and every later partition schema silently skipped its own trigger. Nothing failed — each schema decided the work was already done, because elsewhere it was. This is the identical defect V44 repaired for the sibling trigger mesh_node_copy_to_history, in one of the same methods. That repair fixed one trigger and left its neighbour. Why it survived: satellite tables were never affected (GetSatelliteTableScript always used the per-table form — 231 correctly installed in the same database), so a partition's _Access/_Thread/_Activity writes notified while that same partition's mesh_nodes writes did not. And the in-process IStorageAdapter.Changes feed still carries same-process writes, so only a notification that had to cross a process boundary was lost, silently. Fix, both halves: - The three scripts now use the per-table DROP/CREATE form the other ~20 triggers in the file already use, so new schemas are correct. - V54 installs the trigger on existing schemas that lack it. It only touches schemas genuinely missing it — CREATE/DROP TRIGGER takes an ACCESS EXCLUSIVE lock and this loop runs over every partition on the server — and it reports how many were missing rather than just reporting success. mesh_node_copy_to_history needs no data repair: measured 33/33 already present (V44 covered every existing schema). Its source-side guard in GetMeshSchemaScript is fixed alongside so a NEW schema cannot regress. 🚨 That third site was found BY THE TEST, not by eye. The test rejects the SHAPE — any trigger created under a guard that checks only a name, without constraining the table — which is why it caught an instance a targeted fix would have missed. It carries a negative control (the real guard must still be flagged) and its complement (a properly table-scoped probe must still be allowed), so it cannot quietly become vacuous. Verified: Release + -warnaserror clean (Hosting.PostgreSql, Database.Migration, Documentation); 9/9 tests pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

This PR fixes a PostgreSQL schema-provisioning defect where the mesh_node_notify trigger was installed only once per database (due to a globally-scoped pg_trigger name probe), leaving most partition schemas without pg_notify emissions for node writes. It updates the schema DDL to install the trigger per-table and adds a v54 migration + tests to prevent regressions.

Changes:

Update partition/unversioned schema scripts to DROP TRIGGER IF EXISTS … ON mesh_nodes; CREATE TRIGGER … (per-table, non-global) for mesh_node_notify (and align mesh_node_copy_to_history similarly where applicable).
Add migration V54 to install mesh_node_notify on existing schemas that are missing it, and register it as DbVersion.Latest = 54.
Add tests that scan generated schema SQL to forbid globally-scoped pg_trigger.tgname guards and assert that mesh_node_notify is created via the per-table form.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
test/MeshWeaver.Hosting.PostgreSql.Test/MeshNodeNotifyTriggerScriptTests.cs	Adds regression tests to forbid database-global trigger-name guards and assert per-table trigger creation.
src/MeshWeaver.Hosting.PostgreSql/PostgreSqlSchemaInitializer.cs	Switches trigger installation to per-table `DROP/CREATE` form; exposes unversioned script for test coverage.
src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-18-partition-writes-notify-again.md	Adds a “What’s New” entry documenting the defect and fix.
memex/aspire/Memex.Database.Migration/Migrations/V54_FixMeshNodeNotifyTriggerPerSchema.cs	New migration that installs `mesh_node_notify` for schemas that lack it.
memex/aspire/Memex.Database.Migration/MigrationRegistry.cs	Registers the new V54 migration.
memex/aspire/Memex.Database.Migration/DbVersion.cs	Bumps latest DB version from 53 to 54.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

+                await using (var cmd = ctx.DataSource.CreateCommand($"""
+                    CREATE TRIGGER mesh_node_notify
+                        AFTER INSERT OR UPDATE OR DELETE ON {quotedSchema}.mesh_nodes
+                        FOR EACH ROW EXECUTE FUNCTION notify_mesh_node_changes();
+                    """))


    /// <summary>
    /// Returns SQL for unversioned partitions: core tables only, no history table or triggers.
    /// </summary>


github-actions · 2026-08-17T23:00:02Z