From: | Jiří Hlinka <jiri(dot)hlinka(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Deadlock detected after pg_repack receives SIGINT |
Date: | 2015-11-06 07:08:38 |
Message-ID: | CADCCO5qTVCsgqTrjUf0BjkT=iz+fBVdocbARLVVV-pPL+CoOPQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi Kevin,
my point was, that pg_repack deadlocked itself - I think it should be
possible to guarantee deadlock-free behavior at least via advisory lock for
operations of pg_repack itself (I understand it is not possible to
guarantee this across more apps). If it is not true, I'd be glad to hear
I'm wrong (really!).
Thanks,
Jiri
On Thu, Nov 5, 2015 at 5:43 PM, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
> On Thursday, November 5, 2015 12:16 AM, Jiří Hlinka <jiri(dot)hlinka(at)gmail(dot)com>
> wrote:
>
> > My opinion is, that pg_repack should guarantee a consistent,
> > deadlock-free behaviour via proper locking policy
>
> I would be very interesting in seeing a description of what locking
> policy would guarantee deadlock-free behavior when run concurrently
> with unknown software. If you have a link to a paper on the topic,
> that would serve as well as a description here.
>
> --
> Kevin Grittner
> EDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
--
Bc. Jiří Hlinka
Tel.: 725 315 263
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-11-06 07:17:35 | Re: Deadlock detected after pg_repack receives SIGINT |
Previous Message | Jeff Janes | 2015-11-06 06:06:06 | Re: Lock contention in TransactionIdIsInProgress() |