At Wed, 21 Jun 2017 22:43:32 -0400, Peter Eisentraut 
<peter.eisentr...@2ndquadrant.com> wrote in 
> 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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to