Waiting for PostgreSQL 19 – Add CONCURRENTLY option to REPACK – select * from depesz;

PostgreSQL 19 is gaining a CONCURRENTLY option for the REPACK command, allowing table repacking (to reclaim bloat) without holding an access-exclusive lock for the entire operation. The lock is only needed at the final relfilenode swap. A practical test on a 200M-row table (19 GB with 80% bloat) showed the table shrinking to ~4 GB in about 65 seconds, with concurrent inserts experiencing only moderate slowdown (average latency rising from 1.5ms to 5.5ms) rather than being blocked entirely. Known limitations include replication slot consumption, only one concurrent REPACK at a time system-wide, and a deadlock risk during the final lock upgrade phase — all slated to be addressed in follow-up commits.