Postgres 19's REPACK moves the exclusive lock from the whole rewrite to the file swap

The rewrite is the easy part to reason about. REPACK (CONCURRENTLY) copies the heap into a new file while the old one keeps accepting writes, captures what changed using logical decoding, replays it, and only then takes a brief lock to swap the files ^[8]. Two cost terms, and the benchmark separates them. Sixteen connections committing 1,120 updates a second landed 16,228 writes during the rewrite of a 1549 MB table, and replaying that backlog took two tenths of a second ^[11]. Divide 16,228 by 1,120 and the rewrite ran about 14.5 seconds, which puts replay at roughly 1.4 percent of the window ^[19]. The author's reading is that almost all of the cost is the sequential scan, which does not care how busy the table is ^[12].

That is the figure to interrogate before assuming it transfers. Scan cost tracks heap size; the backlog to replay tracks scan time multiplied by write rate. The tables here ran 424 MB to 1549 MB with two indexes over three million tuples ^[4][10], and the whole operation finished in seconds. A heap that takes minutes to scan accumulates proportionally more change to replay at the same commit rate, and nothing in this test measures what replay costs at that size. The new pg_stat_progress_repack view is the instrument for finding out, since it reports phase, heap blocks scanned, tuples, and indexes rebuilt ^[10].

The end of the operation is where the availability claim takes its asterisk. The slowest write during the concurrent run was 125 ms, and that is the swap ^[9]. CONCURRENTLY still needs ACCESS EXCLUSIVE for that swap, asks for it at the end, and if another session is holding the table it waits with a pending exclusive request that everything arriving afterwards queues behind ^[14]. One session idle in a transaction that touched the table is enough to convert a command chosen for availability into a stall of a length nobody controls, and it lands after the expensive work is already spent. Cancellation, at least, is well behaved: a cancel one second into a repack of a 1 GB table left the table at 2,000,000 rows and 1033 MB, added nothing to the database, and left no replication slot ^[13].

The post raises the schema question but leaves the restriction unnamed. It opens by saying one of the restrictions is something you would want to fix on your own schedule rather than discover during an upgrade, then gives its length to lock behaviour and breaks off mid-sentence in a second lock-queue run without naming the restriction ^[16]. Logical decoding is the mechanism ^[8], which narrows where such a requirement would live, but the rule itself is not in this evidence, and a restriction nobody has stated is not something a DBA can audit against. Beta 3 is beta 3, and the author says as much ^[3].

What CONCURRENTLY buys is not only writes. A single connection looping a keyed count against a 1.1 GB table got exactly one read through a VACUUM FULL ^[6]. Where there is a genuine window and nothing running, the post's own advice is plain REPACK ^[15]. Reach for CONCURRENTLY and the price appears twice: about four and a half times the duration ^[17], and a lock request at the end that you had better be certain nothing is sitting in front of ^[14].