On Tue, Nov 3, 2015 at 9:51 PM, Jiří Hlinka <jiri.hlinka@gmail.com> wrote:
> After the 10 min timeout, the OS sends SIGINT to pg_repack process so the
> pg_repack calls:
> SELECT repack.repack_drop($1, $2)
> and it causes a deadlock with other process which is INSERTing into
> frequently_updated_table that has a pg_repack's trigger to log every change
> to a repack.log_[OID of frequently_updated_table].
Recalling memories from this stuff, that's part of a cleanup rollback,
right? A repack can be a lengthy operation on relations that are
heavily updated as pg_repack keeps a trace of each DML event that
happens to the source table and then replays them one by one.
> Is it a bug of pg_repack or am I doing something wrong? Should I add some
> detailed info?
I doubt there is anything involving Postgres here. It seems that some
process is still holding a lock on a relation that is being dropped,
caused by a race condition in pg_repack code.
> PS: I was trying a mailing list of pg_repack
> (http://lists.pgfoundry.org/pipermail/reorg-genera) and github without any
> notice. If there is better place to ask, tell me, please.
I guess you should let those folks time to answer. If I were you I'd
begin first by letting more time for the repack operation to complete.
Regards,
--
Michael