Re: [HACKERS] Get stuck when dropping a subscription duringsynchronizing table
От | Masahiko Sawada |
---|---|
Тема | Re: [HACKERS] Get stuck when dropping a subscription duringsynchronizing table |
Дата | |
Msg-id | CAD21AoAhPHOxgtUeXUcYYnAacw_JOhDv+Je-WGB52QvZdeAgCg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Get stuck when dropping a subscription duringsynchronizing table (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Get stuck when dropping a subscription duringsynchronizing table
|
Список | pgsql-hackers |
On Tue, Jun 20, 2017 at 10:55 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 6/1/17 13:37, Petr Jelinek wrote: >> On 01/06/17 17:32, Masahiko Sawada wrote: >>> On Thu, May 25, 2017 at 5:29 PM, tushar <tushar.ahuja@enterprisedb.com> wrote: >>>> After applying all your patches, drop subscription no more hangs while >>>> dropping subscription but there is an error "ERROR: tuple concurrently >>>> updated" in the log file of >>>> standby. >>> >>> I tried to reproduce this issue with latest four patches I submit but >>> it didn't happen. I guess this issue doesn't related to the issues >>> reported on this thread and another factor might be cause of this >>> issue. It would be good to test the same again with latest four >>> patches or after solved current some open items. >> >> That's because your additional patch kills the workers that do the >> concurrent update. While that's probably okay, I still plan to look into >> making the subscription and state locking more robust. > > It seems we have gotten off track here a bit. What is the current > proposal to fix "tuple concurrently updated" during DROP SUBSCRiPTION? I think there is no proposal for it so far. The current proposal is to fix this problem during ALTER SUBSCRIPTION. > 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. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: