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
