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 1neE3D-0005o3-I4 for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Apr 2022 10:47:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1neE3B-0000pI-7v for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Apr 2022 10:47:09 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1neE3A-0000mJ-Sc for pgsql-hackers@lists.postgresql.org; Tue, 12 Apr 2022 10:47:08 +0000 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1neE38-0003pD-6b for pgsql-hackers@lists.postgresql.org; Tue, 12 Apr 2022 10:47:07 +0000 Received: by mail-ej1-x62b.google.com with SMTP id bv19so13473281ejb.6 for ; Tue, 12 Apr 2022 03:47:06 -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=gCN6qV+OKbXKnQQs4UBrohb34Sya73WC3y4fhKyHZPQ=; b=Tr0+bCiOhL3FH55HLGXocX7LtgkTySE2a2fmVUwH++91U8TxgIhXaetLH4BoX/gG7k v9fRJeEGDbEFfKFvbdbNxL/nJ4dYuzG6oyHiMDrzwB9vZPbV2ZWPfvtmH/h5ATeup2/8 MpM8SBn7TO3kPIMmZowLIG6uRfXYt6xrcHOOAWZ9fd36204PgY6A+mbcxiEfPdscuR0W Mn8iGOnyBpuTMO+tBKiqEE7rYZk9X+Zol6mhq4wGqfA9NpR2k6Mkxk9L/pgqdLYDfADH CZYzTnf7mpa1VauaZLhfdoqi6zu6DBJbhEAPhqCOoj2vtd4sb54IQfMIdkjZAJmPx7td cGeg== 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=gCN6qV+OKbXKnQQs4UBrohb34Sya73WC3y4fhKyHZPQ=; b=qxOv3f0AKMMncSD/8xXkKqkCI/gf/odH4Tw2JVSFNP7f8aqPZfaiojTQ3CPdWWeamR zhjwHsqnaiTxN1TGZac0szZ9kefkh9Q3stqbhjBTysD7UN6neKDjPvMUZe7Mq7Hr+hJ6 /c9cMeJ3fkfy0AIpbFy2gt7KjAzyWcBAayc2ssZpp9+db5dBwfdKjxWVYUKW29iTJtH6 WzVPy8tpFLoKcUPaFqc0oPt6EHtTbW2XorTswK9Lx950ugeqr/Zbd1ZgUMRTlm+5276h Uyz2jNomGdMsMXmn66ussndJDlB+NZ7kQb7r7Jgha8CD23bP5+s0o/p7bVEAGao1PUUX IjmQ== X-Gm-Message-State: AOAM530isu6Fmae4Q/8RK9/1eSAzrO4tTCH3idENvCcOc0E3MZ/G2VpE cBzx8aOMZGzcJkjb3YOu3qxbhDlCBvzCLtwnGqE= X-Google-Smtp-Source: ABdhPJxiaxfRJAocA5aCGhoC4Of8TvJTpQJ+lLsP9IMHwn8JGYz0HkcU9KYJc8V3hU9PZ0r9Qu+H2GxDidVVu6s8k+s= X-Received: by 2002:a17:907:1c96:b0:6db:57e5:3e2f with SMTP id nb22-20020a1709071c9600b006db57e53e2fmr33670912ejc.705.1649760424515; Tue, 12 Apr 2022 03:47:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: vignesh C Date: Tue, 12 Apr 2022 16:16:53 +0530 Message-ID: Subject: Re: Skipping schema changes in publication To: Amit Kapila Cc: 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 Tue, Apr 12, 2022 at 12:19 PM Amit Kapila wrote: > > On Tue, Apr 12, 2022 at 11:53 AM vignesh C wrote: > > > > On Sat, Mar 26, 2022 at 7:37 PM vignesh C wrote: > > > > > > On Tue, Mar 22, 2022 at 12:38 PM vignesh C wrote: > > > > > > > > Hi, > > > > > > > > This feature adds an option to skip changes of all tables in specified > > > > schema while creating publication. > > > > This feature is helpful for use cases where the user wants to > > > > subscribe to all the changes except for the changes present in a few > > > > schemas. > > > > Ex: > > > > CREATE PUBLICATION pub1 FOR ALL TABLES SKIP ALL TABLES IN SCHEMA s1,s2; > > > > OR > > > > ALTER PUBLICATION pub1 ADD SKIP ALL TABLES IN SCHEMA s1,s2; > > > > > > > > A new column pnskip is added to table "pg_publication_namespace", to > > > > maintain the schemas that the user wants to skip publishing through > > > > the publication. Modified the output plugin (pgoutput) to skip > > > > publishing the changes if the relation is part of skip schema > > > > publication. > > > > As a continuation to this, I will work on implementing skipping tables > > > > from all tables in schema and skipping tables from all tables > > > > publication. > > > > > > > > Attached patch has the implementation for this. > > > > > > The patch was not applying on top of HEAD because of the recent > > > commits, attached patch is rebased on top of HEAD. > > > > The patch does not apply on top of HEAD because of the recent commit, > > attached patch is rebased on top of HEAD. > > > > I have also included the implementation for skipping a few tables from > > all tables publication, the 0002 patch has the implementation for the > > same. > > This feature is helpful for use cases where the user wants to > > subscribe to all the changes except for the changes present in a few > > tables. > > Ex: > > CREATE PUBLICATION pub1 FOR ALL TABLES SKIP TABLE t1,t2; > > OR > > ALTER PUBLICATION pub1 ADD SKIP TABLE t1,t2; > > > > For the second syntax (Alter Publication ...), isn't it better to > avoid using ADD? It looks odd to me because we are not adding anything > in publication with this sytax. I was thinking of the scenario where user initially creates the publication for all tables: CREATE PUBLICATION pub1 FOR ALL TABLES; After that user decides to skip few tables ex: t1, t2 ALTER PUBLICATION pub1 ADD SKIP TABLE t1,t2; I thought of supporting this syntax if incase user decides to add the skipping of a few tables later. Thoughts? Regards, Vignesh