Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nR6eK-0004st-6x for pgsql-hackers@arkaria.postgresql.org; Mon, 07 Mar 2022 06:15:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nR6eI-000362-8Z for pgsql-hackers@arkaria.postgresql.org; Mon, 07 Mar 2022 06:15:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nR6eH-00035t-Te for pgsql-hackers@lists.postgresql.org; Mon, 07 Mar 2022 06:15:13 +0000 Received: from mail-qv1-xf36.google.com ([2607:f8b0:4864:20::f36]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nR6eF-000617-QE for pgsql-hackers@lists.postgresql.org; Mon, 07 Mar 2022 06:15:13 +0000 Received: by mail-qv1-xf36.google.com with SMTP id kd28so2846726qvb.2 for ; Sun, 06 Mar 2022 22:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QRqwAWbdVquxQ7WkKcwnZXyekSoEJkLJBmW3xWvayIM=; b=AJ40JqwJEAcpCyaXnJh3M3LGNbTjadE0+V74dg75JAtox6z84Ghp1qT6ipdS1wPiV+ gJQM++zOvQkvqYozcMxrpmX3o/C99Gt01IuTZr6h5IDWI4xFjw9T9rZ23LjyOXJ4mxB6 o19KBl3C0uliQdOoZwgcY4QLSiQ0guRO2R0sOvLtgDAj0pGNJYjrO+DRzlndCdndGtGC hqWkNQpDJO3Cs35LmygWRMR16CcPy00rlRHKCYUbUKwkGvnZGQx8MWhZLhI7o/NUXJD/ FLLTprSYAlsoJStSokVxPfxLz2dIuPmaSaIEjBHCg82m3BcGY2eoJp+uOC1cOaic2KWI cchQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QRqwAWbdVquxQ7WkKcwnZXyekSoEJkLJBmW3xWvayIM=; b=V/8vV25PmoiSzuESmh5YuA8a7HDrbQeFf1CzCPQ2f3Sq5vBSVPBJmYLDQ5ovcKGyKi e1e/cXaNeE0CEFShEeO2xP5Pbg0ZFXe9hkd7BpMFdr25wbIJaFHlZALcCLIdrVWFGHl9 FavT6ynq1xCvCLAv4qo8pBn2EagqJ4grDURR6KpUYXln1dX8eW9wGrZ7d1P6w0TeF8gC eBFA1WNYA7LC5L0uogE8JFaRI3M/n9jgtyF6MczdhvCLyYURKG0Fwu+sTYd8IPUCHuWV RHS1y018sZv4KPAoito9X7sqElDeR8dIviT+gByLxrM7LCT9/hIQh+18BSg4dhMx+K6d h+mA== X-Gm-Message-State: AOAM5312SSLbaZ3h2M2agYn/mrn5qcD2g1VmRedrn62VOf0ceTZy0BPW j+PSSksDfV08wbnmdHlNRaySlonbdiasOL5nyzGzPK2ImKA= X-Google-Smtp-Source: ABdhPJytPnSiPL9pz5bReUa/cwiM07odcfyuSQioTtekWD/LKwejiBSW/b0C+/ZiSZ8b85Rqp/CxmmpgyePg+9Zq3AE= X-Received: by 2002:ad4:5bc9:0:b0:435:8ee0:f9b8 with SMTP id t9-20020ad45bc9000000b004358ee0f9b8mr2559382qvt.82.1646633709807; Sun, 06 Mar 2022 22:15:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Peter Smith Date: Mon, 7 Mar 2022 17:14:48 +1100 Message-ID: Subject: Re: Handle infinite recursion in logical replication setup To: vignesh C Cc: "kuroda.hayato@fujitsu.com" , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Mar 7, 2022 at 4:20 PM vignesh C wrote: > > On Mon, Mar 7, 2022 at 10:26 AM Peter Smith wrote: > > > > Hi Vignesh, I also have not looked at the patch yet, but I have what > > seems like a very fundamental (and possibly dumb) question... > > > > Basically, I do not understand the choice of syntax for setting things up. > > > > IMO that "only-local" option sounds very similar to the other > > PUBLICATION ("publish") options which decide the kinds of things that > > will be published. So it feels more natural for me to think of the > > publisher as being the one to decide what will be published. > > > > e.g. > > > > option 1: > > CREATE PUBLICATION p1 FOR TABLE t1; > > CREATE SUBSCRITION s1 ... FOR PUBLICATION p1 WITH (only_local = true); > > > > option 2: > > CREATE PUBLICATION p1 FOR TABLE t1 WEHRE (publish = 'only_local'); > > CREATE SUBSCRITION s1 ... FOR PUBLICATION p1; > > > > ~~ > > > > IIUC the patch is using option 1. My first impression was it feels > > back-to-front for the SUBSCRIPTION telling the PUBLICATION what to > > publish. > > > > So, why does the patch use syntax option 1? > > I felt the advantage with keeping it at the subscription side is that, > the subscriber from one node can subscribe with only_local option on > and a different subscriber from a different node can subscribe with > only_local option as off. This might not be possible with having the > option at publisher side. Having it at the subscriber side might give > more flexibility for the user. > OK. Option 2 needs two publications for that scenario. IMO it's more intuitive this way, but maybe you wanted to avoid the extra publications? node0: CREATE PUBLICATION p1 FOR TABLE t1; CREATE PUBLICATION p1_local FOR TABLE t1 WITH (publish = 'only_local'); node1: CREATE SUBSCRIPTION s1 ... FOR PUBLICATION p1_local; node2: CREATE SUBSCRIPTION s1 ... FOR PUBLICATION p1; ------ Kind Regards, Peter Smith. Fujitsu Australia