On 2019-11-18 09:53, Amit Langote wrote:
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.
Right. Without that second part, the first part isn't really that
useful yet, is it?
I'm not sure what your intent with this patch is now. I thought the
previous behavior -- add a partitioned table to a publication and its
leaf tables appear in the replication output -- was pretty welcome. Do
we not want that anymore?
There should probably be an option to pick the behavior, like we do in
pg_dump.
What happens when you add a leaf table directly to a publication? Is it
replicated under its own identity or under its ancestor partitioned
table? (What if both the leaf table and a partitioned table are
publication members?)
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
