On Fri, Nov 6, 2015 at 4:08 PM, Jiří Hlinka <jiri.hli...@gmail.com> wrote: > my point was, that pg_repack deadlocked itself - I think it should be > possible to guarantee deadlock-free behavior at least via advisory lock for > operations of pg_repack itself (I understand it is not possible to guarantee > this across more apps). If it is not true, I'd be glad to hear I'm wrong > (really!).
Er, well. Based on the information given there is actually no evidence that pg_repack is actually deadlocked. The code path calling the cleanup callback after receiving SIGINT waiting for the transaction working on the trigger being dropped to finish. We could say that there is a deadlock if the transaction inserting data to repack.log% is actually holding a lock that conflicts with the trigger being dropped. -- Michael -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
