Hello, At Wed, 21 Jun 2017 22:43:32 -0400, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote in <501f75c9-c5d6-d023-add0-3b670ac86...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
