On Tue, Nov 12, 2019 at 10:11 AM Amit Langote <amitlangot...@gmail.com> wrote: > Initial > syncing code can be easily modified to support any combination of > source and target relations, but changes needed for real-time > replication seem non-trivial.
I have spent some time hacking on this. With the attached updated patch, adding a partitioned table to publication results in publishing the inserts, updates, deletes of the table's leaf partitions as inserts, updates, deletes of the table itself (it all happens inside pgoutput). So, the replication target table doesn't necessarily have to be a partitioned table and even if it is partitioned its partitions don't have to match one-to-one. One restriction remains though: partitioned tables on a subscriber can't accept updates and deletes, because we'd need to map those to updates and deletes of their partitions, including handling a tuple possibly moving from one partition to another during an update. Also, I haven't added subscription tests yet. Attached updated patch. The previous division into a refactoring patch and feature patch no longer made to sense to me, so there is only one this time. Thanks, Amit
v5-0001-Support-adding-partitioned-tables-to-publications.patch
Description: Binary data