Обсуждение: Re: [HACKERS] [BUGS] BUG #14699: Statement trigger and logical replication

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.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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.

- Andres

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

On 6/17/17 08:29, Euler Taveira wrote:
> 2017-06-16 22:08 GMT-03:00 Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com
> <mailto:peter.eisentraut@2ndquadrant.com>>:
> 
> 
>     The issue is that the logical replication initial data copy fires a
>     statement trigger for INSERT, because it's implemented as a COPY
>     internally.
> 
> We should document such behavior. AFAICS we discuss later if we should
> provide an option to fire statement triggers during initial copy.

I have added the documentation.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services