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 1nR5nj-00029o-3a for pgsql-hackers@arkaria.postgresql.org; Mon, 07 Mar 2022 05:20:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nR5nh-0001ZN-MG for pgsql-hackers@arkaria.postgresql.org; Mon, 07 Mar 2022 05:20:53 +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 1nR5nh-0001ZE-Bo for pgsql-hackers@lists.postgresql.org; Mon, 07 Mar 2022 05:20:53 +0000 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nR5nc-0005d3-Cd for pgsql-hackers@lists.postgresql.org; Mon, 07 Mar 2022 05:20:53 +0000 Received: by mail-ed1-x530.google.com with SMTP id h13so6112815ede.5 for ; Sun, 06 Mar 2022 21:20:48 -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=Jssi1hd6Q+KiNOfz4vNikym4eG+5th/enXWYjyIL/2o=; b=L54AjYTE9bJNksU7sBb9TXUvEVpAKXpZVfueD2scGDQT9njT/5VSjVPKWW6ZlwiYoD gR0IZR/kdJbqr8YDMKamebvmEkOWBke+Harp4AgSpXTWAR6P4EAl4FPsQsSAZeUXfng5 +HPOZesQ6x81ePACQrjAW4PUcu8Kd2yi/IBaqqaQhaphKM9fi0h/mkM0K0x8SxlMae+x OGI8Pi+HHCNczFDUAyo59nAjivKwkx8E9lSX5B10CkBx91HU3JxjmyGgJluHYJPT/u33 lgQh0C+gKAxCdcsXePn5BJr2OSElK5Z2XTF7CfwrciO0Cl0BDGg/TvqhoyUkb/zrSr5u R+QA== 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=Jssi1hd6Q+KiNOfz4vNikym4eG+5th/enXWYjyIL/2o=; b=bro6rjoOn8QAB7UDARwM+yOungrMqEfL9xAnIsrC4c4OC+cn0H3c8LQ5sCJ+GymlOr hVeNx11rTG4qzs4Fq+ihWYxv4W8vi7ZMjqD12XvhZb6KB3Bi7FGdTX8v2OHeid3+6Uqd jbG81yJ5O84a8Zc3vcgbS0zy68e4wuHDGicJnwt5ZzsbkjMVOrhQeomv0ph0u8SbxEg0 NuaYpHBDSPDDwnPGYo2GPaJYqQOWEg10yFLGLvknPLhqArXhn8hOD5CQ8UGIBayfHNax GD/wNO7HAEYlDULDkrBq4KPT6TBbGXioJ75cRwUhLAfJZ52imu8pySCjnUYUH/ptnEgq rHaQ== X-Gm-Message-State: AOAM531k7AcjyQ6E4QVEKuqnbD+1ckptvdqXPkoNZfXfNUdyIPM+ad0b 3/m5Di725jwSZ5H/ZQZL3VAabrxBbjYe6gpIGDU= X-Google-Smtp-Source: ABdhPJzCCTqBmCpDna8P/7kMn8HKCo2L/cb5xzk32SEEnCuvn+HAb8Z+QB31U8/OF9keHk7CfaEJVuG80QeysRj0XIk= X-Received: by 2002:aa7:d384:0:b0:415:e2f0:1a21 with SMTP id x4-20020aa7d384000000b00415e2f01a21mr9288590edq.230.1646630446046; Sun, 06 Mar 2022 21:20:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: vignesh C Date: Mon, 7 Mar 2022 10:50:35 +0530 Message-ID: Subject: Re: Handle infinite recursion in logical replication setup To: Peter Smith 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 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. Regards, Vignesh