public inbox for [email protected]
help / color / mirror / Atom feedRe: Understanding conflicts on publications and subscriptions
2+ messages / 2 participants
[nested] [flat]
* Re: Understanding conflicts on publications and subscriptions
@ 2024-07-30 13:52 Koen De Groote <[email protected]>
2024-07-30 14:04 ` Re: Understanding conflicts on publications and subscriptions David G. Johnston <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Koen De Groote @ 2024-07-30 13:52 UTC (permalink / raw)
To: PostgreSQL General <[email protected]>
Just to add a thought:
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.
On Tue, Jul 30, 2024 at 3:47 PM Koen De Groote <[email protected]> wrote:
> Reading this document:
> https://www.postgresql.org/docs/16/logical-replication-conflicts.html
>
> There is talk of the "disable_on_error" option when creating a
> subscription.
>
> The conflicts this applies to, I am assuming are only conflicts caused on
> the side of the subscription?
>
> As an attempt to apply new data doesn't work, because of modifications
> made since the initial copy, is that correct?
>
>
> I'm a bit confused by errors on the side of the publisher. Reading this
> document: https://www.postgresql.org/docs/16/sql-createpublication.html
>
> It states:
>
> > The tables added to a publication that publishes UPDATE and/or DELETE operations
> must have REPLICA IDENTITY defined. Otherwise those operations will be
> disallowed on those tables.
>
> This is not related to the subscription option "disable_on_error", I take
> it?
>
> Because it sure would be nice if there was a way to do a similar thing for
> the subscription, disabling it on error.
>
> Am I getting this right? "disable_on_error" is only on subscription, and
> errors on the publishers related to replica identity are not tied to that?
>
> Thanks for your time.
>
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Understanding conflicts on publications and subscriptions
2024-07-30 13:52 Re: Understanding conflicts on publications and subscriptions Koen De Groote <[email protected]>
@ 2024-07-30 14:04 ` David G. Johnston <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: David G. Johnston @ 2024-07-30 14:04 UTC (permalink / raw)
To: Koen De Groote <[email protected]>; +Cc: PostgreSQL General <[email protected]>
On Tuesday, July 30, 2024, Koen De Groote <[email protected]> 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.
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-07-30 14:04 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-07-30 13:52 Re: Understanding conflicts on publications and subscriptions Koen De Groote <[email protected]>
2024-07-30 14:04 ` David G. Johnston <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox