On Sat, Jun 17, 2017 at 1:22 PM, Andres Freund <andres@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.eisentraut@2ndquadrant.com
>> > <mailto:peter.eisentraut@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