Re: [GENERAL] Deadlock detected after pg_repack receives SIGINT

On 11/5/15 12:14 AM, Jiří Hlinka wrote: I'm doing simple UPDATES, INSERTs and DELETEs on this table, but frequency of these DMLs is _very_ high (it is a queue table used for a one-way selective [just part of data are replicated] replication of queries between two instances of the database, lets

Re: [GENERAL] Deadlock detected after pg_repack receives SIGINT

On Thursday, November 5, 2015 12:16 AM, Jiří Hlinka wrote: > My opinion is, that pg_repack should guarantee a consistent, > deadlock-free behaviour via proper locking policy I would be very interesting in seeing a description of what locking policy would guarantee

Re: [GENERAL] Deadlock detected after pg_repack receives SIGINT

Hi Kevin, 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

Re: [GENERAL] Deadlock detected after pg_repack receives SIGINT

On Fri, Nov 6, 2015 at 4:08 PM, Jiří Hlinka 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

Re: [GENERAL] Deadlock detected after pg_repack receives SIGINT

On Wed, Nov 4, 2015 at 10:16 PM, Jiří Hlinka wrote: > I'm on pg_repack 1.3.2 (latest sable, no devel version available to check > if it is already fixed). > > Michael: your memories are fresh and clear :-), yes, it is part of a > cleanup rollback. The problem is, that the

Re: [GENERAL] Deadlock detected after pg_repack receives SIGINT

I'll check if the trigger activity was moving on or waiting for a lock from logs. I'm doing simple UPDATES, INSERTs and DELETEs on this table, but frequency of these DMLs is _very_ high (it is a queue table used for a one-way selective [just part of data are replicated] replication of queries

Re: [GENERAL] Deadlock detected after pg_repack receives SIGINT

Thanks Jim and Michael for comments. I'm on pg_repack 1.3.2 (latest sable, no devel version available to check if it is already fixed). Michael: your memories are fresh and clear :-), yes, it is part of a cleanup rollback. The problem is, that the pgrepack_drop call this statement: DROP TABLE IF

[GENERAL] Deadlock detected after pg_repack receives SIGINT

I'm running a pg_repack from a bash script with timeout of 10 minutes like so (simplified version): timeout -s SIGINT 10m pg_repack --table=frequently_updated_table 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

Re: [GENERAL] Deadlock detected after pg_repack receives SIGINT

On 11/3/15 7:44 AM, Michael Paquier wrote: 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

Re: [GENERAL] Deadlock detected after pg_repack receives SIGINT

On Tue, Nov 3, 2015 at 9:51 PM, Jiří Hlinka 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 >