On Tue, Nov 3, 2015 at 9:51 PM, Jiří Hlinka <jiri.hlinka@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
