Re: Deadlock detected after pg_repack receives SIGINT

From: Jiří Hlinka <jiri(dot)hlinka(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Deadlock detected after pg_repack receives SIGINT
Date: 2015-11-04 13:16:03
Message-ID: CADCCO5qF2Pfgr-r0kAvxQqKs_z3ZEY-WLCjqit-bfRECU0joiA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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 EXISTS repack.log_%u CASCADE

...and it collides with this trigger inserting new touples inside the [
frequently_updated_table] in the repack.log_[OID of
frequently_updated_table] routine:

SELECT 'CREATE TRIGGER z_repack_trigger'
' BEFORE INSERT OR DELETE OR UPDATE ON ' || repack.oid2text($1) || ' FOR
EACH ROW EXECUTE PROCEDURE repack.repack_trigger(' || '''INSERT INTO
repack.log_' || $1 || '(pk, row) VALUES(' || ' CASE WHEN $1 IS NULL THEN
NULL ELSE (ROW($1.' || repack.get_index_columns($2, ', $1.') ||
')::repack.pk_' || $1 || ') END, $2)'')';

As these two actions are both run by pg_repack, it seems like a bug to me
as pg_repack should not be able to deadlock itself, but not 100% sure about
this part...

On Wed, Nov 4, 2015 at 3:48 AM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:

> 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.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.
>>
>
> Make sure you're on the latest version too. There were some recent commits
> aimed at fixing some race conditions.
> --
> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
> Experts in Analytics, Data Architecture and PostgreSQL
> Data in Trouble? Get it in Treble! http://BlueTreble.com
>

--
Bc. Jiří Hlinka
Tel.: 725 315 263

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bertrand Roos 2015-11-04 13:32:37 Auto-analyse on insert operations
Previous Message dinesh kumar 2015-11-04 13:00:03 Re: Query regarding