[BUG]: `enriched_events` is left partitioned but never registered with pg_partman, and `migrate.sh` exits 0

[mbucknam]

Describe the bug

After a clean ./scripts/migrate.sh against an empty database, enriched_events exists and is
declared PARTITION BY RANGE, but it is not registered with pg_partman. partman.part_config
has no row for it, and the only child table is enriched_events_default. Every row therefore lands
in the catch-all default partition, and no monthly partitions are ever created or maintained.

migrate.sh exits 0. There is no error, no warning, and nothing in the log at default level.

This is not a pg_partman problem and not a managed-database problem — it reproduces on
getlago/postgres-partman:15.0-alpine, the image this project ships.

To Reproduce

1. Start the reference database image:

   docker network create lagorepro
   docker run -d --name pgpartman --network lagorepro \
     -e POSTGRES_PASSWORD=repro -e POSTGRES_USER=lago -e POSTGRES_DB=lago \
     getlago/postgres-partman:15.0-alpine

2. Confirm the extension is present — it is, version 5.4.0:

   docker exec pgpartman psql -U lago -d lago -tAc \
     "select extversion from pg_extension where extname='pg_partman'"

3. Run the migration against it:

   docker run --rm --network lagorepro \
     -e RAILS_ENV=production \
     -e DATABASE_URL=postgresql://lago:repro@pgpartman:5432/lago \
     -e SECRET_KEY_BASE=... -e LAGO_RSA_PRIVATE_KEY=... \
     -e LAGO_ENCRYPTION_PRIMARY_KEY=... -e LAGO_ENCRYPTION_DETERMINISTIC_KEY=... \
     -e LAGO_ENCRYPTION_KEY_DERIVATION_SALT=... \
     getlago/api:v1.52.1 ./scripts/migrate.sh

   It exits 0.

4. Inspect the result:

   SELECT relkind FROM pg_class
    WHERE relname='enriched_events' AND relnamespace='public'::regnamespace;
   -- p   (partitioned, as expected)
   
   SELECT count(*) FROM partman.part_config
    WHERE parent_table='public.enriched_events';
   -- 0   (expected: 1)
   
   SELECT c.relname FROM pg_inherits i JOIN pg_class c ON c.oid=i.inhrelid
    WHERE i.inhparent='public.enriched_events'::regclass;
   -- enriched_events_default   (and nothing else)

Expected behavior

partman.create_parent succeeds, partman.part_config gains a row for public.enriched_events, and
pg_partman creates monthly partitions from 2024-12-01 plus three premade ahead — the parameters the
migration itself passes.

Failing that, the migration should raise, so the operator learns about it during deployment rather
than months later.

Check	Expected	Actual
migrate.sh exit code	0	0
pg_partman installed	yes	yes (5.4.0)
enriched_events is relkind='p'	yes	yes
Row in partman.part_config	1	0
Monthly partitions	~25	0 — only the default
Warning or error anywhere	—	none

Screenshots

N/A — server-side, output shown above.

Support

Not a browser issue, so the equivalents:

• Deployment: Docker, self-hosted
• Lago version: v1.52.1 (getlago/api:v1.52.1); also reproduced on v1.52.0
• Database: getlago/postgres-partman:15.0-alpine — PostgreSQL 15.0, pg_partman 5.4.0
• OS: Linux x86_64

Additional context

pg_partman is working correctly. A control test in the same session, issuing the identical
create_parent call from db/migrate/20260109132143_partition_enriched_events.rb against a freshly
created partitioned table, returned t, wrote the part_config row, and built 26 partitions. So the
extension functions; the migration's invocation of it does not take effect.

Probable mechanism. partman.create_parent appears to return false rather than raising. After the
migration, both partman.template_public_enriched_events and enriched_events_default exist —
artifacts create_parent creates early — but there is no part_config row. Because execute sees no
exception, the migration is recorded as applied and the script exits 0.

Compounding it, both 20260109092932_setup_partman.rb and 20260109132143_partition_enriched_events.rb
guard on pg_extension_present?("pg_partman") and return quietly if it is absent, logging only at
debug. Between a silent guard and a create_parent that fails without raising, there is no signal
at all — we confirmed zero lines mentioning partman or create_parent in the full migration output.

Why this matters. The failure is silent and the consequence is delayed. An operator has no reason to
suspect anything is wrong until the table misbehaves months later, and by then every row is in an
unbounded default partition — which is worse than no partitioning, since it carries all of the
overhead and none of the benefit, and makes attaching real partitions progressively more expensive.

Suggested fix.

• Check the boolean returned by create_parent and raise if it is false.
• Log at warn rather than debug when the partman guard skips.

Workaround, safe only while the default partition is still empty:

ALTER TABLE public.enriched_events DETACH PARTITION public.enriched_events_default;
DROP TABLE public.enriched_events_default;

SELECT partman.create_parent(
  p_parent_table    := 'public.enriched_events',
  p_control         := 'timestamp',
  p_interval        := '1 month',
  p_type            := 'range',
  p_premake         := 3,
  p_start_partition := '2024-12-01'
);

UPDATE partman.part_config
SET infinite_time_partitions = true,
    retention                = '14 months',
    retention_keep_table     = true
WHERE parent_table = 'public.enriched_events';

[AlexeyShalaev]

Adding a related finding rather than opening a second issue, because it lands on whoever is in the state this report describes: the recovery procedure in docs/database_partitioning.md ("Retroactive setup") does not work, and one of its steps destroys the copy you would need to retry.

Anyone who reads #787, finds their rows in enriched_events_default, and follows that section to fix it ends up worse off than when they started.

Two independent defects, both reproduced

Reproduced on ghcr.io/pgmq/pg17-pgmq (pg_partman 5.x; any server with the extension does), following the documented steps verbatim with a stub table carrying only id and timestamp:

1. Step 3 creates a default partition that create_parent then collides with.

Step 3 ends with

CREATE TABLE public.enriched_events_default PARTITION OF public.enriched_events DEFAULT;

but pg_partman creates its own default partition under exactly that name. On an empty parent, step 7 fails:

ERROR:  relation "enriched_events_default" already exists

2. Steps 5–7 are in the wrong order, so registration cannot succeed.

Step 5 copies every historical row into the parent while only the default partition exists, so all of it lands in enriched_events_default. Step 7 then asks pg_partman to create the dated partitions covering those same rows, which PostgreSQL refuses:

ERROR:  updated partition constraint for default partition "enriched_events_default"
        would be violated by some row

Step 8 does not rescue it. The text says to "trigger a first maintenance run to create the monthly partitions and move data out of the default partition into the correct ones" — run_maintenance_proc() does not move data. It returns cleanly and changes nothing:

CALL
-- rows still in enriched_events_default: 8
-- child partitions: 1  (the default)

Moving rows out of a default partition is partition_data_time / partition_data_proc, not run_maintenance.

And step 6 has already dropped enriched_events_old by then — the only other copy — so the operator is left with their whole event history in an unregistered default partition, no dated partitions, and nothing to retry from.

A sequence that does work

Same steps, minus the manual default, with registration before the data move. Verified: 8 rows in, 8 rows out, 0 left in the default partition, 26 partitions created.

-- 1-2. as documented: install the extension, rename the existing table

-- 3. create the partitioned parent, and NOTHING else — no manual default partition
CREATE TABLE public.enriched_events (...) PARTITION BY RANGE ("timestamp");

-- 4. recreate indexes, as documented

-- 5. register FIRST, while the parent is still empty; this creates the dated
--    partitions and pg_partman's own default
SELECT partman.create_parent(
    p_parent_table   := 'public.enriched_events',
    p_control        := 'timestamp',
    p_interval       := '1 month',
    p_type           := 'range',
    p_premake        := 3,
    p_start_partition := '2024-12-01'   -- must be at or before your oldest row
);
UPDATE partman.part_config
   SET infinite_time_partitions = true, retention = '14 months', retention_keep_table = true
 WHERE parent_table = 'public.enriched_events';

-- 6. only now migrate the data; every row routes into its month
INSERT INTO public.enriched_events SELECT * FROM public.enriched_events_old;

-- 7. verify before destroying anything
SELECT count(*) FROM public.enriched_events_default;   -- expect 0
SELECT count(*) FROM public.enriched_events;           -- expect the old row count

-- 8. drop the old table last
DROP TABLE public.enriched_events_old;

Two things worth saying in the doc alongside it: p_start_partition has to be at or before the oldest row, since anything earlier still has no partition and lands in the default; and the verification in step 7 is the point where a mistake is still recoverable, which is precisely what the current ordering removes.

For an installation that is already in the #787 state — rows in the default partition, nothing registered, old table long gone — the same shape works but the partitions have to be created before the rows can move: detach the default, create the covering partitions explicitly, move the rows back, truncate and reattach, all in one transaction. Happy to write that out if it would be useful; it is fiddlier and I would rather test it against the real schema than post it from a stub.

---

Disclosure: I maintain a PostgreSQL partition-lifecycle library, which is why I was reading partitioning setups across projects and found this. Nothing here involves it — Lago's setup is pg_partman and this is a docs ordering bug in it.

[Tyagiquamar]

Taking this on: implementing the corrected Retroactive-setup sequence from the Sep-4 repro (no manual default partition, register-before-move with p_start_partition at/before oldest row, partition_data_proc instead of run_maintenance for the move, verify counts including 0 rows in default before dropping the old table). Will open a docs fix shortly.