On Sat, Jun 17, 2017 at 1:22 PM, Andres Freund <and...@anarazel.de> wrote: > On 2017-06-16 21:08:44 -0400, Peter Eisentraut wrote: >> On 6/16/17 09:13, Константин Евтеев wrote: >> > 2017-06-13 5:57 GMT+03:00 Peter Eisentraut >> > <peter.eisentr...@2ndquadrant.com >> > <mailto:peter.eisentr...@2ndquadrant.com>>: >> > >> > I think this is all working correctly and as intended. >> > >> > But then, why data copy for init logical replication fires statement >> > trigger. May be it is also not nedeed? >> > Or this feature needs to be mentioned in documentation? >> >> I don't know. Hackers? >> >> The issue is that the logical replication initial data copy fires a >> statement trigger for INSERT, because it's implemented as a COPY internally. >> >> By contrast, the normal apply worker does not fire any statement >> triggers (because they are not "statements"). >> >> We could adjust one or the other or leave it as is. > > Leave it as is.
I also noticed this while working on the open items for transition tables. One of my patches adds a comment to execReplication.c about the need to do a bit more work if/when statement triggers are fired here in future. I assume that we'll eventually want statement triggers to fire if eager incremental matviews depend on that (as is proposed), or if that set-oriented FK check idea goes somewhere. Transition tables make statement triggers a lot more powerful (something like batch-mode after row triggers). -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers