I have had clients who have run into problems with it, however. In particular, it is possible to get it wedged so that the table is inaccessible and nothing can proceed, unless you either kill the repack operation or kill what is blocking it. Here is a simple example of how to cause problems.
In session 1, do:
pg_repack -e -t foo dbnameset
and in session 2 in psql do:
The sleep gets us past the time when pg_repack is setting up, and happens while it is is doing its CREATE TABLE ... AS SELECT .... When that CREATE TABLE statement finishes, both sessions will be wedged. Session 2 will be hung because it is unable to lock the table, since pg_repack's other session will hold a weak lock on the table. And nothing, including pg_repack, will be able to do anything with the table.select pg_sleep(10); lock table foo; rollback;
The solution is to make sure that nothing holds or even tries to obtain any strong long running locks on the table.
One useful thing is to use the check_postgres.pl monitor script to look for things like long running transactions and processes waiting for locks.
Or you can create a more customized test to look for this exact situation.
Most importantly, you need to be aware that problems can occur, and to protect against them happening in the first place.