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.na...@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
