Re: subscription disable_on_error not working after ALTER SUBSCRIPTION set bad conninfo - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: subscription disable_on_error not working after ALTER SUBSCRIPTION set bad conninfo
Date
Msg-id CAA4eK1LvDL2EDXSZoKKX3RUJdM2jwMMWn32dnHZCYobAJCDh-Q@mail.gmail.com
Whole thread Raw
In response to Re: subscription disable_on_error not working after ALTER SUBSCRIPTION set bad conninfo  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: subscription disable_on_error not working after ALTER SUBSCRIPTION set bad conninfo
Re: subscription disable_on_error not working after ALTER SUBSCRIPTION set bad conninfo
List 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 by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: cleanup patches for incremental backup
Next
From: Ashutosh Bapat
Date:
Subject: Re: Report planning memory in EXPLAIN ANALYZE