Re: Understanding conflicts on publications and subscriptions

David,

By "addition" do you mean "adding the table to the publication"? I suppose
that's an option, though I was more thinking about disabling the
publication if an error occurs, similarly to how a subscription is disabled
if "disable_on_error" is set to true, and an error occurs there.

However, thinking about that is fantasizing, at this point.

My main worry is understanding the behavior as it is. And if my
understanding is correct: if a table doesn't have a replica identity, any
UPDATE or DELETE statement that happens on the publisher, for that table,
will be refused.

Is that correct?

Regards,
Koen

On Tue, Jul 30, 2024 at 4:04 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Tuesday, July 30, 2024, Koen De Groote <kdg(dot)dev(at)gmail(dot)com> wrote:
>>
>> If the subscriber gets a bit of logic to say "Something went wrong, so
>> I'm automatically stopping what I'm doing", it sounds logical to give the
>> publisher the same ability.
>>
>
> The wording for that option is:
> Specifies whether the subscription should be automatically disabled if
> any errors are detected by subscription workers during data replication
> from the publisher.
>
> A subscription worker has no clue what the publisher is doing. It
> operates on the “when I see data I act on it” model.
>
> As for whether the publisher should have this clause - the errors in
> question are logical, data-oriented, errors, which the publisher is
> incapable of having.
>
> I believe what you are effectively requesting is that instead of
> disallowing updates and deletes on the added table that lacks replica
> identity you wish for the addition itself to fail. That would have made a
> better default behavior with an option to override when the current
> behavior is desired. But it seems too late to change this decision now.
>
> David J.
>