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 s
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 guarantee
> this across more
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
I'
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 deadlock-free behavior when ru
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 betw
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 pgrepack_drop call this
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
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
>(http://lists.pgfoun
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
> frequently_updated_table that has a pg_repac
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 c
10 matches
Mail list logo
