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 1nu8yw-00007N-4H for pgsql-hackers@arkaria.postgresql.org; Thu, 26 May 2022 08:36:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nu8yt-00031G-Um for pgsql-hackers@arkaria.postgresql.org; Thu, 26 May 2022 08:36:31 +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 1nu8yt-000317-Jt for pgsql-hackers@lists.postgresql.org; Thu, 26 May 2022 08:36:31 +0000 Received: from mail-pg1-x52e.google.com ([2607:f8b0:4864:20::52e]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nu8yr-00050u-2m for pgsql-hackers@lists.postgresql.org; Thu, 26 May 2022 08:36:31 +0000 Received: by mail-pg1-x52e.google.com with SMTP id h186so803326pgc.3 for ; Thu, 26 May 2022 01:36:28 -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:content-transfer-encoding; bh=rmcpf2sqDCdzJ72MHn8Xw4ULobGOPEDvBDUa6cY73Vs=; b=I2WUJfkO6rM9syLEaQm0BEdZYyodoPwbT+L7C5XDY2s8k9ZuDrAxZueVJfOAz6fx/b okU5lh2z1jOClnW5mJ9BA9va3KTZcIjzya0ywahi5tlqxTKMhxvJNot9nCBBZpWnau1m HCbhd+0EFB/p3CHYjkxmRGpPHBDsU80caCMG/etyg4GaWw7yM31WRIWC7NVFwY2xd+ev wBLi3mWfUf/Cb3bjp9H4eQt38d71QK5nU0JKLse1roxC/oSRIun+u1JXskTRczfGttyX dGDXiXoMCvUpwVf9hpgd86K3LIlvlomWXq4/I15ezDaFW0iVzORwGcrsOExfoiec88Nd si4w== 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:content-transfer-encoding; bh=rmcpf2sqDCdzJ72MHn8Xw4ULobGOPEDvBDUa6cY73Vs=; b=6KJRCTCjGydjSAijsyPXNb3u0rNmCt3BSkouEeDi1ZJLoF+bQ5RSqp4dTFRO0m4K6q ea0cATkJUXbNT8rjHkJIyUD5kwhahcGj5QeRZXMC7IvZMbccS3OfkZHIv8lJ1FbJX0Ro qfq+z46vsGME+rWdA/30PU9GSPRdR0gTYoOAPLY1KRZZAW3+jK6Cc5axB+QmKj7+nt+b anwhmsld+hYrq4IgQddEWVj5PA7ODZ9zr3LaLpDvhq5NbSfluhd2igsLNbcdn/m2L1tA oUe5UJM0rAEm5/2euvQ/Wwe6VEJR7qmqJZOlAACssvFjIbQG8BWiJYbvgUdq1r3iXyoC WgxQ== X-Gm-Message-State: AOAM5328KHTI572rNAawdDs8uwxkt5Qmn9NQpi+UYqvWlVl7M1y74k7I MWLkklODUlktetgHKMhAQelhQLZaT0BnqNZjG6w= X-Google-Smtp-Source: ABdhPJxDh0mgSLFSCDS6FpjOKoiWIkdPyktWRiX8K8nUkVl+71jGmGm4njaRQFZ/tmEs12ZlI38HeB5TqZar8fF72/g= X-Received: by 2002:a63:fe08:0:b0:3fa:b2bd:e616 with SMTP id p8-20020a63fe08000000b003fab2bde616mr9651235pgh.114.1653554187014; Thu, 26 May 2022 01:36:27 -0700 (PDT) MIME-Version: 1.0 References: <202203162206.7spggyktx63e@alvherre.pgsql> In-Reply-To: From: Masahiko Sawada Date: Thu, 26 May 2022 17:35:50 +0900 Message-ID: Subject: Re: Support logical replication of DDLs To: Zheng Li Cc: Amit Kapila , Japin Li , Alvaro Herrera , Dilip Kumar , rajesh singarapu , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, May 14, 2022 at 6:02 AM Zheng Li wrote: > > > > 4. The handling related to partition tables seems missing because, on > > > the subscriber-side, it always creates a relation entry in > > > pg_subscription_rel which won't work. Check its interaction with > > > publish_via_partition_root. > > > > I will test it out. > > Hi, > > patch 0010 properly handles partitioned table creation on the apply > worker. Whether a replicated partitioned table should be added to > pg_subscription_rel catalog depends on the setting of > publish_via_partition_root of the publication. Thus we need to connect > to the source DB and check if the partitioned table is in > pg_catalog.pg_publication_tables after the apply worker creates the > partitioned table. > > Thanks to Borui Yang for enabling and testing replication of DDL type > T_RenameStmt in patch 0009. > > I've also rebased all the patches. Github branch of the same change > can be found here: > https://github.com/zli236/postgres/commits/ddl_replication Thank you for updating the patches! I've not looked at these patches in-depth yet but with this approach, what do you think we can handle the DDL syntax differences between major versions? DDL syntax or behavior could be changed by future changes and I think we need to somehow deal with the differences. For example, if the user uses logical replication for major version upgrade, the publisher is older than the subscriber. We might have to rewrite the DDL before applying to the subscriber because the DDL executed on the publisher no longer work on a new PostgreSQL version or we might have to add some options to the DDL before the application in order to keep the same behavior. This seems to require a different solution from what the patch does for the problem you mentioned such as "DDL involving multiple tables where only some tables are replicated=E2=80=9D. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/