Re: subscription disable_on_error not working after ALTER SUBSCRIPTION set bad conninfo

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: subscription disable_on_error not working after ALTER SUBSCRIPTION set bad conninfo
Дата
Msg-id CAA4eK1LvDL2EDXSZoKKX3RUJdM2jwMMWn32dnHZCYobAJCDh-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: subscription disable_on_error not working after ALTER SUBSCRIPTION set bad conninfo  (Peter Smith <smithpb2250@gmail.com>)
Ответы Re: subscription disable_on_error not working after ALTER SUBSCRIPTION set bad conninfo  (Peter Smith <smithpb2250@gmail.com>)
Re: subscription disable_on_error not working after ALTER SUBSCRIPTION set bad conninfo  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
On Thu, Jan 18, 2024 at 11:15 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Thu, Jan 18, 2024 at 12:55 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> ...
> >
> > Although we can improve it to handle this case too, I'm not sure it's
> > a bug. The doc says[1]:
> >
> > Specifies whether the subscription should be automatically disabled if
> > any errors are detected by subscription workers during data
> > replication from the publisher.
> >
> > When an apply worker is trying to establish a connection, it's not
> > replicating data from the publisher.
> >
> > Regards,
> >
> > [1]
https://www.postgresql.org/docs/devel/sql-createsubscription.html#SQL-CREATESUBSCRIPTION-PARAMS-WITH-DISABLE-ON-ERROR
> >
> > --
> > Masahiko Sawada
> > Amazon Web Services: https://aws.amazon.com
>
> Yeah, I had also seen that wording of those docs. And I agree it
> leaves open some room for doubts because strictly from that wording it
> can be interpreted that establishing the connection is not actually
> "data replication from the publisher" in which case maybe there is no
> bug.
>

As far as I remember that was the intention. The idea was if there is
any conflict during apply that users manually need to fix, they have
the provision to stop repeating the error. If we wish to extend the
purpose of this option for another valid use case and there is a good
way to achieve the same then we can discuss but I don't think we need
to change it in back-branches.

--
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Matthias van de Meent
Дата:
Сообщение: Re: cleanup patches for incremental backup
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Report planning memory in EXPLAIN ANALYZE