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 1nRRyJ-0006Lv-6g for pgsql-hackers@arkaria.postgresql.org; Tue, 08 Mar 2022 05:01:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nRRyI-0001l2-5f for pgsql-hackers@arkaria.postgresql.org; Tue, 08 Mar 2022 05:01:18 +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 1nRRyH-0001ih-Q8 for pgsql-hackers@lists.postgresql.org; Tue, 08 Mar 2022 05:01:17 +0000 Received: from mail-qv1-xf2d.google.com ([2607:f8b0:4864:20::f2d]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nRRyB-00011L-Iq for pgsql-hackers@lists.postgresql.org; Tue, 08 Mar 2022 05:01:17 +0000 Received: by mail-qv1-xf2d.google.com with SMTP id p8so10860344qvg.12 for ; Mon, 07 Mar 2022 21:01: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=HkvUwN/uJGLQWWnXrBfUIxLKvCP8obA43SkG+vFEhR0=; b=hLDuFbu47vgEcPVBXykdb5pZIcrGLg19249HHnB+OB2E6X1LEnwFlqGM5gjhATmPJr ixV/PLGbCj7DiY9CTfM+sAw7DPTji6TCTwDmENg5f3QLdrottG4JHv93tzrUlmgai4A6 5kxagxbBokKCmkXjUWytpWTJxMSiH4gxpRFSONns0w0vxgGXO5+O4f8/tnduIKjOjUC+ UxfraVPJO3SYjrLK80GLdr6LLba0juuZmOekhQ2BhY1gFMvUtwDeJHkXeweq0LhK8yIe wtRZQwObzOXX9dck/WLzJV7HNliJOFYgi/u9pSTbx0Y8V5rkMGejUxc5oBiEnmrZlMqI 5ICg== 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=HkvUwN/uJGLQWWnXrBfUIxLKvCP8obA43SkG+vFEhR0=; b=359uWdmw57tNvhhg6Yzz2KiqpxoW1MPckBSA5RdbQj6d4avGO0NOfSbQNbFes0HUZS MDGZrxxmCVO5IrWy4RRVMHoIXZZxJ3lSTQxnqZDB9x7bh/ZE64jjOqAPGP7ucZ8BJvC+ ojnSdpO9X/rnbrB0QeIhL9AcR6G61NUyRNba7QtHhZa6DsjNL07gjlU07seOURh550a1 XuBgvo+OEyXtYg9rf5zbdjm6TjeBbFJo4uNZ7sbGR8lWT3sfZoEkh1VCedPCCN8wRZsb fobXzQvm+uLIf/W7mneWSlsXpEhoJKU38h5OPYcJMTJn/HFyeABmePLT5PVvWWIzL1VW s3WQ== X-Gm-Message-State: AOAM533GWOQbUG70JkarFaGhaGlU51u1t1h8gxjZvVkAuw63B7MOge4Z OcOyI8ffoduchh3T1feZqVOyjp2T3SwY4iB/zuA= X-Google-Smtp-Source: ABdhPJwofoloLSqjsRIj0dWyw5Bm+kzsECVY6Lfu2dipZuXtSkokiO8a/nlRS8yH+Kp5Ehop0l5+6o3zPXdOg2Ayr9E= X-Received: by 2002:ad4:5ecf:0:b0:435:4ebd:881d with SMTP id jm15-20020ad45ecf000000b004354ebd881dmr10489467qvb.41.1646715669710; Mon, 07 Mar 2022 21:01:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Peter Smith Date: Tue, 8 Mar 2022 16:00:45 +1100 Message-ID: Subject: Re: Handle infinite recursion in logical replication setup To: vignesh C Cc: Amit Kapila , Ashutosh Bapat , "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 IIUC the new option may be implemented subscriber-side and/or publisher-side and/or both, and the subscriber-side option may be "enhanced" in future to prevent cycles. And probably there are more features I don't know about or that have not yet been thought of. ~~ Even if the plan is only to implement just one part now and then add more later, I think there still should be some consideration for what you expect all possible future options to look like, because that may affect current implementation choices. The point is: - we should take care so don't accidentally end up with an option that turned out to be inconsistent looking on the subscriber-side / publisher-side. - we should try to avoid accidentally painting ourselves into a corner (e.g. stuck with a boolean option that cannot be enhanced later on) ------ Kind Regards, Peter Smith. Fujitsu Australia