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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to