On 4 April 2018 at 03:31, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> I wonder why this approach was chosen.
I looked at coding it that way and it seemed worse than the way chosen.
> I'm going to try to hack up an alternative approach and see how it works
> out.
If you add a new filter for TRUNCATE it will mean compatibility
problems and the need for pg_dump support.
Need note in release notes to explain that people will need to add
TRUNCATE filter to their existing publications. I was hoping to have
that picked up automatically, which can't happen if we have an
explicit filter for it.
>> I know this has been discussed in the thread already, but it really
>> strikes me as wrong to basically do some mini DDL replication feature
>> via per-command WAL records.
Don't really understand that comment.
> I think TRUNCATE is special in some ways and it's reasonable to treat it
> specially. Real DDL is being worked on in the 2PC decoding thread.
> What we are discussing here isn't going to be applicable there and vice
> versa, I think. In fact, one of the reasons for this effort is that in
> BDR TRUNCATE is currently handled like a DDL command, which doesn't work
> well.
Agreed
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services