From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Get stuck when dropping a subscription during synchronizing table |
Date: | 2017-06-22 02:43:32 |
Message-ID: | 501f75c9-c5d6-d023-add0-3b670ac86de2@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/20/17 19:10, Peter Eisentraut wrote:
> On 6/19/17 22:54, Masahiko Sawada wrote:
>>> It seems to me we could just take a stronger lock around
>>> RemoveSubscriptionRel(), so that workers can't write in there concurrently.
>>
>> Since we reduced the lock level of updating pg_subscription_rel by
>> commit 521fd4795e3e the same deadlock issue will appear if we just
>> take a stronger lock level.
>
> I was thinking about a more refined approach, like in the attached
> patch. It just changes the locking when in DropSubscription(), so that
> that doesn't fail if workers are doing stuff concurrently. Everything
> else stays the same.
The alternative is that we use the LockSharedObject() approach that was
already alluded to, like in the attached patch. Both approaches would
work equally fine AFAICT.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
0001-WIP-Add-locking-SetSubscriptionRelState.patch | text/plain | 1.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-06-22 02:44:54 | Re: Get stuck when dropping a subscription during synchronizing table |
Previous Message | Etsuro Fujita | 2017-06-22 02:25:43 | Re: Useless code in ExecInitModifyTable |