* fix(partman): self-heal default-partition conflicts instead of crash-looping
EnsureFuturePartitions died with log.Fatalf when CREATE ... PARTITION OF
failed with SQLSTATE 23514 (check_violation) — Postgres rejects creating a
daily/weekly partition while the default partition still holds a row that
belongs in the new partition's range. A single stray row therefore turned
every startup into a crash loop with no in-app recovery (operator had to
TRUNCATE the default partition by hand).
On 23514, drain exactly the conflicting rows out of the default partition and
attach a fresh partition for the range, in a single transaction: create a
standalone table (without copying identity so original ids re-insert),
DELETE ... RETURNING the in-range rows into it, then ATTACH. If any step
fails the transaction rolls back atomically — rows return to default
untouched, no partition is created, and the next cleanup tick retries. No row
is ever destroyed.
Both startup call sites (operational_logs, activity_log) downgraded from
log.Fatalf to a warning so a partition hiccup degrades to writing into the
default partition rather than taking the server down.
* fix(partman): lock default partition during default-conflict heal
Without the lock, live writers keep routing rows for the missing (current)
period into the default partition while the heal runs; a row committed
between the drain and the ATTACH re-triggers the same 23514 check violation
and rolls the whole heal back, so the retry tick can spin under steady write
load. Locking only the default leaf (not the parent) blocks those inserts
for the heal's short duration while the rest of the table stays readable
and writable.
Addresses CodeRabbit review on #139.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Quick <31828688+Quick104@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
