Re: Added schema level support for publication. - Mailing list pgsql-hackers
From | vignesh C |
---|---|
Subject | Re: Added schema level support for publication. |
Date | |
Msg-id | CALDaNm1wOma56yeOFf_LxHeb9aAr1oY1WPtYHXfBLw=O=3NsLg@mail.gmail.com Whole thread Raw |
In response to | Re: Added schema level support for publication. (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Responses |
Re: Added schema level support for publication.
|
List | pgsql-hackers |
Thanks for your comments Bharath, please find my opinion below. On Sat, Jan 9, 2021 at 8:08 PM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote: > I think this feature can be useful, in case a user has a lot of tables > to publish inside a schema. Having said that, I wonder if this feature > mandates users to create the same schema with same > permissions/authorizations manually on the subscriber, because logical > replication doesn't propagate any ddl's so are the schema or schema > changes? Or is it that the list of tables from the publisher can go > into a different schema on the subscriber? > DDL's will not be propagated to the subscriber. Users have to create the schema & tables in the subscriber. No change in Permissions/authorizations handling, it will be the same as the existing behavior for relations. > Since the schema can have other objects such as data types, functions, > operators, I'm sure with your feature, non-table objects will be > skipped. > Yes, only table data will be sent to subscribers, non-table objects will be skipped. > As Amit pointed out earlier, the behaviour when schema dropped, I > think we should also consider when schema is altered, say altered to a > different name, maybe we should change that in the publication too. > I agree that when schema is altered the renamed schema should be reflected in the publication. > In general, what happens if we have some temporary tables or foreign > tables inside the schema, will they be allowed to send the data to > subscribers? > Temporary tables & foreign tables will not be added to the publications. > And, with this feature, since there can be many huge tables inside a > schema, the initial table sync phase of the replication can take a > while. > Yes this is required. > Say a user has created a publication for a schema with hundreds of > tables in it, at some point later, can he stop replicating a single or > some tables from that schema? > There is no provision for this currently. > IMO, it's better to have the syntax - CREATE PUBLICATION > production_publication FOR ALL TABLES IN SCHEMA production - just > added IN between for all tables and schema. > I'm ok with the proposed syntax, I would like others' opinion too before making the change. > Say a user has a schema with 121 tables in it, and wants to replicate > only 120 or 199 or even lesser tables out of it, so can we have some > skip option to the new syntax, something like below? > CREATE PUBLICATION production_publication FOR ALL TABLES SCHEMA > production WITH skip = marketing, accounts, sales; --> meaning is, > replicate all the tables in the schema production except marketing, > accounts, sales tables. > Yes this is a good use case, will include this change. Thanks for the comments, I will handle the comments and post a patch for this. Regards, Vignesh EnterpriseDB: http://www.enterprisedb.com
pgsql-hackers by date: