Search Postgresql Archives

Re: Deadlock detected after pg_repack receives SIGINT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux