Add pg_repack, so bloated tables can be rewritten without downtime

[acoustid-bot]

Why

The meta dedup deleted 206,838,911 rows from meta and a similar number from track_meta. Deletes do not return space to the filesystem, so meta is still a 62 GB heap holding 180.6M rows — roughly 50 GB of hole, plus another 25 GB in track_meta.

Autovacuum will not recover it. Plain VACUUM only truncates free space at the physical end of a table, and meta's tail is the native-gid era where every row survived the merge, so there is nothing there to truncate. Observed directly: four autovacuum cycles ran on meta during the merge and the heap sat at 62 GB through all of them.

That leaves VACUUM FULL, which holds ACCESS EXCLUSIVE for the entire rewrite — half an hour or more on a 97 GB table, with metadata lookups failing throughout. Not something to do to a live service to recover disk that is untidy rather than scarce.

pg_repack performs the same rewrite online, taking brief locks only at the start and end.

What

One line in the runtime stage, installed from PGDG next to wal2json:

postgresql-$PG_MAJOR-repack

Built from source would have matched pg_acoustid, but the package ships both the extension and the client binary and tracks the PG major automatically, so there is nothing to pin or rebuild on the next upgrade.

Verified

postgresql-18-repack 1.5.3-1 exists in PGDG for both bookworm and trixie, so this does not depend on which suite the base image tracks.

Checked by running the built image rather than trusting a green build:

/usr/bin/pg_repack                                    1.5.3
/usr/lib/postgresql/18/lib/pg_repack.so
/usr/share/postgresql/18/extension/pg_repack--1.5.3.sql
/usr/share/postgresql/18/extension/pg_repack.control

Client and extension are both 1.5.3 — pg_repack refuses to run if they differ, so that is the check that matters.

Deploying

Adds a package to the runtime image; no change to how the image starts or behaves. The pg-* StatefulSets are pets with OnDelete, so picking this up means deleting pods one at a time — replicas first, then a Patroni switchover before the leader. CREATE EXTENSION pg_repack is still needed per database before use.

Note

The commit message says the binary lands in /usr/lib/postgresql/$PG_MAJOR/bin. It is actually /usr/bin/pg_repack. Both are on PATH, so behaviour is unaffected, but the message is wrong on that detail.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 08ec2e9d-18dc-4671-b562-074031416239

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}