Hacker News Reader

Are you aware of pg_repack [1]? I haven't had a chance to use it myself yet, but it's designed for reclaiming bloated space without downtime.

[1] https://github.com/reorg/pg_repack/

View on HN

We tested pg_repack early on. Our experience (at least 5 years ago) was it didn't reliably clean up after itself in all cases so we were left with random triggers in the database. With thousands of customer databases this was a huge potential hassle.

I have heard plenty of people use pg_repack so maybe it got better or we didn't test it enough.

We use pg_repack and hit that exact problem (left over triggers etc). In the end we resorted to creating and dropping the pg_repack extension after each run.

(edit: Missed an "and")

Do you have any idea why their docs are not mentioning this, or even why their software aren't doing that itself?

I haven't used pg_repack in production, but on my development box with PgSQL 10.x, if you end the process early, pg_repack will complain on the next run and ask you to clean up by dropping and re-adding the extension. Maybe this occurs in the wild if the cleanup code is not reached, for whatever reason.

We use pg_repack with automated schedules and it's really helpful.

Reply on news.ycombinator.com