Re: Why ALTER SUBSCRIPTION ... SET (slot_name='none') requires subscription disabled?
От | Japin Li |
---|---|
Тема | Re: Why ALTER SUBSCRIPTION ... SET (slot_name='none') requires subscription disabled? |
Дата | |
Msg-id | MEYP282MB1669B842CF8D851F5F4DAC73B6199@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM обсуждение исходный текст |
Ответ на | Re: Why ALTER SUBSCRIPTION ... SET (slot_name='none') requires subscription disabled? (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Why ALTER SUBSCRIPTION ... SET (slot_name='none') requires subscription disabled?
|
Список | pgsql-hackers |
On Thu, 08 Jul 2021 at 17:51, Amit Kapila <amit.kapila16@gmail.com> wrote: > On Wed, Jul 7, 2021 at 7:25 PM Japin Li <japinli@hotmail.com> wrote: >> >> Hi, hackers >> >> The documentation [1] says: >> >> When dropping a subscription that is associated with a replication slot on the >> remote host (the normal state), DROP SUBSCRIPTION will connect to the remote >> host and try to drop the replication slot as part of its operation. This is >> necessary so that the resources allocated for the subscription on the remote >> host are released. If this fails, either because the remote host is not >> reachable or because the remote replication slot cannot be dropped or does not >> exist or never existed, the DROP SUBSCRIPTION command will fail. To proceed in >> this situation, disassociate the subscription from the replication slot by >> executing ALTER SUBSCRIPTION ... SET (slot_name = NONE). >> >> However, when I try this, it complains the subscription is enabled, this command >> requires the subscription disabled. Why we need this limitation? >> > > If we don't have this limitation then even after you have set the slot > name to none, the background apply worker corresponding to that > subscription will continue to stream changes via the previous slot. > Yeah, thanks for your explain! Should we add some comments here? >> OTOH, when I execute ALTER SUBSCRIPTION ... SET (slot_name=''), it doesn't complain. However, >> SELECT select pg_create_logical_replication_slot('', 'pgoutput') complains slot name is too >> short. Although, the slot will be created at publisher, and validate the slot name, IMO, we >> can also validate the slot_name in parse_subscription_options() to get the error early. >> Attached fixes it. Any thoughts? >> > > Oh, I think this should be fixed. Can anyone else think this to be > valid behavior? > Ranier Vilela provides a v2 patch and reduce the overhead of ReplicationSlotValidateName() in thread [1]. [1] https://www.postgresql.org/message-id/CAEudQAqLtNJ1wvMKLK8ZH27SGJW5OjizgyMq28bFj-_5QG1G+A@mail.gmail.com -- Regrads, Japin Li. ChengDu WenWu Information Technology Co.,Ltd.
В списке pgsql-hackers по дате отправления: