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
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
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
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
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
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
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
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
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
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
>
10 matches
Mail list logo