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