Thanks Jim and Michael for comments.
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@xxxxxxxxxxxxxx> 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_repackI guess you should let those folks time to answer. If I were you I'd
>(http://lists.pgfoundry.org/pipermail/reorg-genera) and github without any
>notice. If there is better place to ask, tell me, please.
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
