Re: [BUGS] BUG #14699: Statement trigger and logical replication

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