On 2/8/18 10:54, amul sul wrote:
> Not really, like ExecUpdate for an update of partition key if delete is failed
> then the further insert will be skipped, but you are correct, it might be more
> tricky than I can think -- there is no guarantee that the next insert operation
> which replication worker trying to replicate is part of the update of partition
> key mechanism. How can one identify that an insert operation on one relation is
> related to previously deleting operation on some other relation?
I think you somehow need to stitch this back together in logical
decoding and publish it as an update operation. Otherwise, wrong things
happen. For example, what happens to a publication that is configured
to only publish inserts? What happens to update triggers on the
receiving table? What if the subscriber side is partitioned differently?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
