Hello,
At Wed, 21 Jun 2017 22:43:32 -0400, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote in
<501f75c9-c5d6-d023-add0-3b670ac86de2@2ndquadrant.com>
> 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.
However I haven't seen this deeply, just making
SetSubscriptionRelState exlusive seems to have a chance to create
a false record on pg_subscription_rel. Am I misunderstanding?
--
Kyotaro Horiguchi
NTT Open Source Software Center