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 1nqr4o-0001Xb-DC for pgsql-hackers@arkaria.postgresql.org; Tue, 17 May 2022 06:53:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nqr4n-0003yw-6o for pgsql-hackers@arkaria.postgresql.org; Tue, 17 May 2022 06:53:01 +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 1nqr4m-0003yn-Sf for pgsql-hackers@lists.postgresql.org; Tue, 17 May 2022 06:53:00 +0000 Received: from mail-yb1-xb35.google.com ([2607:f8b0:4864:20::b35]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nqr4k-0005K8-O2 for pgsql-hackers@lists.postgresql.org; Tue, 17 May 2022 06:53:00 +0000 Received: by mail-yb1-xb35.google.com with SMTP id a3so11836551ybg.5 for ; Mon, 16 May 2022 23:52:57 -0700 (PDT) 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=16zEwrxtm31QZ6ap946vrJKsNyfC58EIo6DoIyw8FmM=; b=ZVDUTCnqy0Yh3ME8xF+lVH0lbCJMuwWym/D/ENuxx21/HdG6BLMbHNPIznnJJOHqNM WO32n8nZcsy89GUh/7qXcBz7N06q9Hxqf7Zl94E7uuzhghp3kqjFTbs4Bcykq09V6uif 6zfgfhWW0chJy6nxpZw/HSpNtvVmrN5co1oQSy+OkqmOZDIuc6Q+ZiqYbWCp2GeqQ0XE 1+DSOZqK8qD5VRSq8QXX9bLbce0s7TNTbyUvWf5KS8D6sPVl5G7DT+kB4w5pGn1hIti5 omL7GLZONLkadMwYDPsuORQAIDdqMrEhw+a8H0UXxP5NdqFXn/7RTWYLaiWj+KrtMdzb mRWw== 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=16zEwrxtm31QZ6ap946vrJKsNyfC58EIo6DoIyw8FmM=; b=n28kEWOSJRUrRzc/pV0qiwi1lc45kFWhLCBBYgwC7s3JHc2wxdGCY7eB1OziQKduRq XDmai7LvW1YL1p1lAxxOjXgV2WsWROjfr23SIjTL1ya1iLouRh2aAKoIMFJrBnNZQJaP SDC3nYdtLrHDpWF7+m+QBvym3JLpTjdskiCcgLM4QPsZisZWezu/+BUwwwro4o1bydwn KXWN375uKkmIx1SFh4k+QY2kji3ANc4rrjWIYaEd4SHdcykFUeT0ornToVs32BFNoDFl ZKExGbHleuOdu/9LbyTFjwtwWU/MIY5DBtStZ/ZiQqtjpqnxk1UhTS4SfaKFVJ/mFVqE uGcg== X-Gm-Message-State: AOAM5307vbdghRVqMMEUhhYkC47kCGK3uG1PZsD/VMYauc6D+76bc2AV 8la4xDNBAflcUGE8OmpjKiT8eGcvqqpuHgYiCAo= X-Google-Smtp-Source: ABdhPJyvBSlt4n76+P9vCrjP5NzcHxhHUMP6Cz0/Nx2Aju5tQMILTMENvL8rIRwyphXDChQtoc6fKcGMG8Lww/CiRmI= X-Received: by 2002:a25:874d:0:b0:64d:c470:c8aa with SMTP id e13-20020a25874d000000b0064dc470c8aamr6541870ybn.578.1652770376337; Mon, 16 May 2022 23:52:56 -0700 (PDT) MIME-Version: 1.0 References: <202205021144.zkbvyekn52v7@alvherre.pgsql> In-Reply-To: From: Amit Kapila Date: Tue, 17 May 2022 12:22:45 +0530 Message-ID: Subject: Re: bogus: logical replication rows/cols combinations To: "houzj.fnst@fujitsu.com" Cc: Tomas Vondra , Alvaro Herrera , Peter Eisentraut , Pg 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, May 16, 2022 at 6:04 PM houzj.fnst@fujitsu.com wrote: > > Attach the new version patch. > Few minor comments: ================== 1. + + Names of table columns included in the publication. This contains all + the columns of table when user didn't specify column list for the + table. + Can we slightly change it to: "Names of table columns included in the publication. This contains all the columns of the table when the user didn't specify the column list for the table." 2. Below comments needs to be removed from tablesync.c as we don't combine column lists after this patch. * For initial synchronization, column lists can be ignored in following * cases: * * 1) one of the subscribed publications for the table hasn't specified * any column list * * 2) one of the subscribed publications has puballtables set to true * * 3) one of the subscribed publications is declared as ALL TABLES IN * SCHEMA that includes this relation 3. Note that we don't support the case where column list is different for + * the same table when combining publications. But we still need to check + * all the given publication-table mappings and report an error if any + * publications have different column list. Can we change this comment to: "Note that we don't support the case where the column list is different for the same table when combining publications. But one can later change the publication so we still need to check all the given publication-table mappings and report an error if any publications have a different column list."? 4. Can we add a test for different column lists if it is not already there? -- With Regards, Amit Kapila.