Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sYneW-00E9Th-4e for pgsql-general@arkaria.postgresql.org; Tue, 30 Jul 2024 14:16:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sYneU-00AWeu-1n for pgsql-general@arkaria.postgresql.org; Tue, 30 Jul 2024 14:16:34 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sYneT-00AWem-Fg for pgsql-general@lists.postgresql.org; Tue, 30 Jul 2024 14:16:33 +0000 Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sYneQ-002Dog-FF for pgsql-general@lists.postgresql.org; Tue, 30 Jul 2024 14:16:32 +0000 Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a7aac70e30dso588618466b.1 for ; Tue, 30 Jul 2024 07:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722348989; x=1722953789; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2h1haR36nX7kcQ6DEP8xPChimrwEUVUOeiGdgHbvMGY=; b=ZZTsq6WsZXgrSkNnTfghP1CKXjlCWkwISk7eAVcYl8N0cjjX5LDt3WlWKGBtn/fgyv Z2zETg99xR3rg+csdqYribvAwUCLR5+oQjb8hariiRmfO973D7tCF6stDvAor2p4vmjk siQmVrGeHXSj1eAOu9c211harLrDwx2h2pfMqlmIxKp0exTZ3ObgIKMABnDWpftadKyd qO9vbbx8X7YZZnMVFTEw0vr4ZHTutP/B/FgzG/2D782gxSRfG5fFc06+nP55gF3vscqP 5+le7gapTz8B/d6KnLhIyePPk/QZ9pEhzsMm9zvwBadU/8lHhQtzmYQZ6JxtMdnMw/l6 2DYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722348989; x=1722953789; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2h1haR36nX7kcQ6DEP8xPChimrwEUVUOeiGdgHbvMGY=; b=kAidyVnF6xfAuzp3Gt6YQWlY8LHY6lmQEL9OYXn6o7INSkw/HjgZnNQmcgXriyCB63 XpEKoLCCuJ3YOCHYFxecl0l0LKw4CKu+r47qgTevFNQ0O+oSRgdCqoSq+rSj+FZwqAph jzntQwAs6T6X18U5Eye7mO0mvERf06TkDu6Gxt3NOjeAqrd17jxxXpXm+YKFywmQeqSW eIzGdAsw5Q85GBGVVCER2J7muNcUxs2nKSefiCFOgMPZro0cOpXIp3R9E7aW+SbwT3et jenF8C0O4SomLoAJ1Qgji1HhvZZmhxuOkGSRcs5DbhUKZdTgkp6/j4d9cdE6H0R+D85u j16A== X-Gm-Message-State: AOJu0YzYGn6oBs4lqk2MTBkmRRh8awXWuF+eKYnNuff9HMTr1lfJcolp W+fKONUubPQeYAzddM1Kha1X8Fy5YPURPLUrwxC5BJuZW57dMnMBI8H2/rWaEus4SIKJvfKDraV +URdx75gdMtb+OXgGfyNkNs+YWwo= X-Google-Smtp-Source: AGHT+IFKJ0pDbc9XZ5x1meKwCHB58YRBXU6dRgTIJnBqSUtza9qA0R18FYcsqSWchudhnpRKxAxr5UXy+wfh4eU8ZlY= X-Received: by 2002:a17:906:d551:b0:a7a:a3f7:389e with SMTP id a640c23a62f3a-a7d3fdb64c2mr943569066b.6.1722348988390; Tue, 30 Jul 2024 07:16:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Koen De Groote Date: Tue, 30 Jul 2024 16:16:16 +0200 Message-ID: Subject: Re: Understanding conflicts on publications and subscriptions To: "David G. Johnston" Cc: PostgreSQL General Content-Type: multipart/alternative; boundary="000000000000a1e564061e779f32" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000a1e564061e779f32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM David G. Johnston < david.g.johnston@gmail.com> wrote: > On Tuesday, July 30, 2024, Koen De Groote 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 th= e >> 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 =E2=80=9Cwhen I see data I act on it=E2=80=9D 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. > --000000000000a1e564061e779f32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
David,

By "addition&quo= t; do you mean "adding the table to the publication"? I suppose t= hat's an option, though I was more thinking about disabling the publica= tion if an error occurs, similarly to how a subscription is disabled if &qu= ot;disable_on_error" is set to true, and an error occurs there.
<= div>
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=E2=80=AFPM David G. Johnston <= david.g.johnston@gmail.com> wrote:
On = Tuesday, July 30, 2024, Koen De Groote <kdg.dev@gmail.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 f= or that option is:
=C2=A0Specifies whether the subscription sh= ould be automatically disabled if any errors are detected by subscription w= orkers during data replication from the publisher.=C2=A0

A subscription worker has no clue what= the publisher is doing.=C2=A0 It operates on the =E2=80=9Cwhen I see data = I act on it=E2=80=9D 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 ha= ving.

I believe what you are e= ffectively requesting is that instead of disallowing updates and deletes on= the added table that lacks replica identity you wish for the addition itse= lf to fail.=C2=A0 That would have made a better default behavior with an op= tion to override when the current behavior is desired.=C2=A0 But it seems t= oo late to change this decision now.

<= div>David J.
--000000000000a1e564061e779f32--