Partition manager cannot reclaim a pre-existing catch-all partition — monthly partitioning silently stops

[frodoHost]

Summary

Once a fresh deployment's initial migration boundary is crossed, ensure_future_partitions can never create the "current month" partition again, because the migration's own *_p_future catch-all already covers that range. The collision is caught and swallowed as a benign, expected case — so partitioning for that range silently and permanently stops, with no error, no metric, and no operator-visible signal beyond a Postgres server-log line most people don't watch.

Where

• migrations/0001_initial_schema.sql (events: lines ~237-252, delivery_log: lines ~343-354) hardcodes monthly partitions with literal dates authored mid-2026, ending with a catch-all:

  CREATE TABLE events_p_future PARTITION OF events
      FOR VALUES FROM ('2026-07-01') TO (MAXVALUE);

  Any fresh install that runs this migration in July 2026 or later will have every monthly partition ensure_future_partitions tries to create fall inside _p_future's range and collide. This isn't an edge case — it will recur for every fresh install going forward, and again at the next catch-all boundary for any host that hand-repairs it (e.g. re-basing to 2027-01-01 just moves the wall to 2027-01).

• crates/buzz-db/src/partition.rs (~lines 130-149) explicitly anticipates this:

  match sqlx::query(sqlx::AssertSqlSafe(sql)).execute(pool).await {
      Ok(_) => { info!("added partition {partition_name}"); Ok(()) }
      Err(sqlx::Error::Database(db_err))
          if db_err.code().as_deref() == Some("42P17")
              && db_err.message().contains("would overlap partition") =>
      {
          // Fresh schemas include a right-edge catch-all partition (`*_p_future`).
          // If it already covers this month, the table is still safe for writes;
          // treat the overlap as "ensured" rather than failing startup.
          info!(partition_name, "partition range already covered by an existing partition");
          Ok(())
      }
      Err(e) => Err(e.into()),
  }

  Postgres error 42P17 ("would overlap partition") is caught and logged at info, then treated as success. Postgres itself still logs a server-side ERROR for the rejected DDL (independent, unsuppressable), but the application never surfaces it, never fails startup, and gives no indication that the monthly partition was never actually created.

Impact

The monthly partition never gets created; nothing ever shrinks or re-splits the existing catch-all. Every row for the colliding range keeps landing in _p_future indefinitely, defeating the purpose of monthly partitioning (pruning/archival/maintenance by partition boundary). There's no code anywhere in partition.rs or in migrations 0002-0026 that ever reclaims or splits an existing catch-all partition once one exists.

Reproduction

A regression test reproducing this against real Postgres (current_month_partition_is_never_created_once_a_future_catchall_exists, crates/buzz-db) is here, passing in CI: frodoHost#1

Suggested fix direction (not implemented)

Either detach-and-recreate the overlapping range of _p_future when a monthly-partition collision is detected, or raise the info! to a warn!/metric so this isn't purely a Postgres-log-only symptom.