On Tue, Jan 23, 2018 at 8:44 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Sat, Jan 20, 2018 at 2:03 AM, Robert Haas <rh...@postgresql.org> wrote: >> Allow UPDATE to move rows between partitions. > > + If an <command>UPDATE</command> on a partitioned table causes a row to > move > + to another partition, it will be performed as a <command>DELETE</command> > + from the original partition followed by an <command>INSERT</command> into > + the new partition. In this case, all row-level <literal>BEFORE</literal> > + <command>UPDATE</command> triggers and all row-level > + <literal>BEFORE</literal> <command>DELETE</command> triggers are fired on > + the original partition. > > Do we need to maintain triggers related behavior for logical > replication? In logical replication, we use ExecSimpleRelationDelete > to perform Delete operation which is not aware of this special > behavior (execute before update trigger for this case).
Hmm. I don't think there's any way for the logical decoding infrastructure to identify this case at present. I suppose if we want that behavior, we'd need to modify the WAL format, and the changes might not be too straightforward because the after-image of the tuple wouldn't be available in the DELETE record. I think the only reason we fire the UPDATE triggers is because we can't decide until after they've finished executing that we really want to DELETE and INSERT instead; by the time we are replicating the changes, we know what the final shape of the operation ended up being, so it's not clear to me that firing UPDATE triggers at that point would be useful. I fear that trying to change this is going to cost performance (and developer time) for no real benefit, so my gut feeling is to leave it alone. However, what do other people think? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
