On 2025-Feb-04, vignesh C wrote: > We should throw an error for partitioned tables that contain foreign > partitions, as this would include the data from these foreign tables > during the initial sync, while incremental changes would not be > replicated.
Hmm, I would support the idea of allowing partitioned tables containing foreign partitions into publications, where only the tuples in non-foreign partitions would be transmitted -- both during initial sync and during replicated DML. This way, any partitioned tables with mixed local and foreign partitions would work okay for replication. If the subscriber wants the data in the foreign partitions, they can create the foreign table on the subscription side and all is well. From a users POV this is probably the most useful. Another aspect is the case where you create the publication first and the foreign table later. I didn't spot in the proposed patch any code that would check whether a publication including this schema exists, which we would have to do if we wanted to be watertight about rejecting publications with foreign tables. But I think that would be a bad direction to go it. I'd rather have the table-listing code for publications skip any foreign tables. For instance, GetPubPartitionOptionRelations() and PublicationAddTables() should skip tables with relkind RELKIND_FOREIGN. The sync code should also silently ignore all foreign tables. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "I am amazed at [the pgsql-sql] mailing list for the wonderful support, and lack of hesitasion in answering a lost soul's question, I just wished the rest of the mailing list could be like this." (Fotis) https://postgr.es/m/200606261359.k5qdxe2p004...@auth-smtp.hol.gr
