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.k5QDxE2p004593@auth-smtp.hol.gr
