Re: Deadlock detected after pg_repack receives SIGINT - Mailing list pgsql-general

From Jiří Hlinka
Subject Re: Deadlock detected after pg_repack receives SIGINT
Date
Msg-id CADCCO5qF2Pfgr-r0kAvxQqKs_z3ZEY-WLCjqit-bfRECU0joiA@mail.gmail.com
Whole thread Raw
In response to Re: Deadlock detected after pg_repack receives SIGINT  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Deadlock detected after pg_repack receives SIGINT
List 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.Nasby@bluetreble.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

pgsql-general by date:

Previous
From: dinesh kumar
Date:
Subject: Re: Query regarding
Next
From: Bertrand Roos
Date:
Subject: Auto-analyse on insert operations