Este post é complemento do post referente ao pg_repack(http://helkmut.blogspot.com.br/2013/11/postgresql-pgrepack.html), onde cito um ponto crítico do repack onde não é viável o rollback.
Um exemplo é caso sua base tenha um crash durante o repack de uma tabela ou por razão desconhecida você tem a conexão do próprio repack terminada. O que acontece nesta situação com sua tabela?
A tabela original possuirá uma trigger enviando todos DMLs para uma tabela temporária de log no schema 'repack' da mesma base de dados, a mesma existirá, pois o processo não foi concluído e a tabela antiga de origem não foi excluída. Assim como existirão os dados da tabela antiga(com outro nome) no schema 'repack' quando o repack foi iniciado.
Então o que fazer?
O primeiro de tudo é isolar a base de dados, fazer uma análise de dados rápida da tabela do schema de origem e a do schema alvo(repack), caso tenhas diferença entre elas significa que podes somente aplicar a tabela de log(DMLs commitados do início do processo até a falha), remover a trigger da tabela de origem, realizar backup das 3 tabelas envolvidas e liberar a base.
Não sendo possível isolar a base de dados para a correção deves remover a trigger da tabela de origem deixando que novos DMLs sejam computados na mesma e não mais na tabela de log e avaliar um método de aplicação dos dados da tabela de log na tabela de origem.
Para um novo repack deverás remover as duas tabelas do schema repack da base de dados alvo.
