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 1sYwBO-00FG5L-M8 for pgsql-general@arkaria.postgresql.org; Tue, 30 Jul 2024 23:23:06 +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 1sYwBL-00Eigt-5E for pgsql-general@arkaria.postgresql.org; Tue, 30 Jul 2024 23:23:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sYwBK-00Eigk-QE for pgsql-general@lists.postgresql.org; Tue, 30 Jul 2024 23:23:02 +0000 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sYwBI-002Kio-07 for pgsql-general@lists.postgresql.org; Tue, 30 Jul 2024 23:23:01 +0000 Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a7a94aa5080so596147966b.3 for ; Tue, 30 Jul 2024 16:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722381778; x=1722986578; 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=pZVybZyH8+xRfPA1JB0f2l4fwJXGz3zH0+K1e1xPWIc=; b=AaNjUCgaITomJePdvYXyiRoA3PjwhxDEyWp8O9v0wnvuFiBZhi3MfU2oqJ6o0334tS rl26MUgbyoVjFXRwHrodLUeRaTegsd9OpAa9o7Yqgpjx7M6u5ksEmJOBCGnDxDYA0q+C s0ls38BZkvd0Vs8zCTNV6d36J2S61KocUM3O89j2kkAF5tfPkEz6fLuquspzTSPSZleo rjfc4BMkR7qhMfa8hhafLnqwY+5puCNrJ3mO54hlRYucOVJ/jyPU/ITv0GnHHx/QEUKz QA2qW1fWTfspAPU2flm1gksRectiEK5biUmhGW/ewlcxYUez/GLyJ/vG5iTpIGp6BUZC GtDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722381778; x=1722986578; 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=pZVybZyH8+xRfPA1JB0f2l4fwJXGz3zH0+K1e1xPWIc=; b=ZXicqrmSp4gm8q7t5FzeTNJAGJJkr8v29P9B6cw1b2PvKezEsJzlTicnU6EC/tG0Ae wZWdZj9Nl/VSYbsBNy+pKJgVc3Tuuk3C8gilubd5vmanvhdRDfpoWOSQMkmp0wHpsvoD LKClCbsVJZ+DZt+Aacn2ZGgsZ6THYsaFot0WHO/nn2cDyuFyqyNfwyZ6XJWXJDZRa0aX VU4JEvYpKla2M5SzKd0tl1fHfL1JkuZ6SGkEWN0v3yolykAUEx+hlDkwSHYUWbZaZ9lH 8WdyZJAlKTP20LW3p3yL3VfkmSPmnRaMcNKcaKwWErj08kqkmht/1v3S3zq86Bo9u0uh JCOQ== X-Gm-Message-State: AOJu0YzZo850dq0duQ3+hlTzX7fTcv9md/6B+S+sbFdkiDIPntmEgXbW yStj3kXZ9pzI8UQGU8kIZG4PODIMXdgjIx6MGSZ+K+t08KI3Wk4aYkhCGH9N8qsjOOvvg9V6QkU 5KukCcT7nmfvIDws1ihs6yRh3V4I= X-Google-Smtp-Source: AGHT+IFdOqCWsPA6cZoFFXZdY3L0rkjSjDwREQH9GaD07xKWqwmAz/MgxHFQi3rpdBmkwkKYJUJG9C3aVd1+7GlzEJI= X-Received: by 2002:a17:906:d551:b0:a7a:a3f7:389e with SMTP id a640c23a62f3a-a7d3fdb64c2mr1050155566b.6.1722381777846; Tue, 30 Jul 2024 16:22:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Koen De Groote Date: Wed, 31 Jul 2024 01:22:45 +0200 Message-ID: Subject: Re: Understanding conflicts on publications and subscriptions To: "David G. Johnston" Cc: PostgreSQL General Content-Type: multipart/alternative; boundary="000000000000094a6a061e7f42ab" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000094a6a061e7f42ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It indeed seems to be that. My initial thought of " will be disallowed on those tables" was "on the subscriber side". After all, why have a publication be of any effect if there's nobody subscribing to it. But it appears the publication influences behavior, regardless of there being a subscriber, which feels counter-intuitive to me. Thanks for stepping me through it. On Tue, Jul 30, 2024 at 4:34=E2=80=AFPM David G. Johnston < david.g.johnston@gmail.com> wrote: > On Tue, Jul 30, 2024 at 7:16=E2=80=AFAM Koen De Groote wrote: > >> 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. >> >> > That is how I read the sentence "Otherwise those operations will be > disallowed on those tables." > > Upon adding said table to a publication, future attempts to run updates > and deletes will result in failures in the transactions performing said D= ML. > > Feel free to experiment that the behavior indeed matches the wording in > the documentation. > > David J. > > --000000000000094a6a061e7f42ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It indeed seems to be that.

= My initial thought of " will be disallowed on those tables" was "on the subscriber side&q= uot;. After all, why have a publication be of any effect if there's nob= ody subscribing to it.

But it appears the publicat= ion influences behavior, regardless of there being a subscriber, which feel= s counter-intuitive to me.

Thanks for stepping me = through it.

On Tue, Jul 30, 2024 at 4:34=E2=80=AFPM David G. Johns= ton <david.g.johnston@gmai= l.com> wrote:
On Tue, Jul 30, 2024 at 7:16=E2=80=AFAM Koen De Gro= ote <kdg.dev@gmai= l.com> wrote:
=C2=A0An= d if my understanding is correct: if a table doesn't have a replica ide= ntity, any UPDATE or DELETE statement that happens on the publisher, for th= at table, will be refused.

=
That is how I read the sentence "Otherwise those operatio= ns will be disallowed on those tables."

Upon ad= ding said table to a publication, future attempts to run updates and delete= s will result in failures in the transactions performing said DML.
=
Feel free to experiment that the behavior indeed matches the w= ording in the documentation.

David J.

--000000000000094a6a061e7f42ab--