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

Reply via email to