Re: Deadlock detected after pg_repack receives SIGINT

[Michael Paquier <michael.paquier@xxxxxxxxx>]

On Wed, Nov 4, 2015 at 10:16 PM, Jiří Hlinka <jiri.hlinka@xxxxxxxxx> 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 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...

Is the trigger activity moving on or is this one waiting as well for a lock? It sounds like pg_repack is waiting for the end of the transaction running this trigger to finish before being able to drop the trigger and this relation safely. I guess that you are running large UPDATE queries, right? It really looks like you should let more room to pg_repack to do its stuff.
--

Michael