BDR truncate and replication sets

Sylvain MARECHAL wrote:

Hello all,

To avoid replication of some tables, I use a specific replication set.
For example, with 2 nodes 'node1' and 'node2' and a table 'test' which
content shall not be replicated, I do the following:

mydb=# CREATE TABLE test (i INT PRIMARY KEY NOT NULL);
mydb=# SELECT bdr.table_set_replication_sets('test', ARRAY['test_rep_set']);

After that, adding (INSERT) or removing (DELETE) data in 'node1' or 'node2'
can be done independently.
The exception is with TRUNCATE: In case it is called, data is removed on
both nodes.

Is it a feature or a bug?

I think it's an oversight. Replication sets were added later than the
TRUNCATE trigger, so the design for the latter does not consider the
former as far as I know.

(I am not sure it is related with
https://github.com/2ndQuadrant/bdr/issues/93)

Doesn't look related.

Is there a workaround?
(deleting the truncate trigger seems to work, but I am sure it is safe to do
it)

Well, the truncate trigger is there to replicate the truncate to other
servers. If you don't want truncate to be propagated, dropping the
trigger is one way to achieve that effect.

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Le 15/09/2015 18:56, Alvaro Herrera a �crit :

Sylvain MARECHAL wrote:

[...] The exception is with TRUNCATE: In case it is called, data is removed on
both nodes.

Is it a feature or a bug?

I think it's an oversight. Replication sets were added later than the
TRUNCATE trigger, so the design for the latter does not consider the
former as far as I know.

Ok. May I fill a bug report?

[...] Is there a workaround?
(deleting the truncate trigger seems to work, but I am sure it is safe to do
it)

Well, the truncate trigger is there to replicate the truncate to other
servers. If you don't want truncate to be propagated, dropping the
trigger is one way to achieve that effect.

Ok. That is what I will do.
In fact, having TRUNCATE do its job on all nodes is sometimes useful,
sometimes unwanted. So this workaround is perfect for me for the moment.

Thank you,
Sylvain

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Sylvain MARECHAL wrote:

Le 15/09/2015 18:56, Alvaro Herrera a �crit :

Sylvain MARECHAL wrote:

[...] The exception is with TRUNCATE: In case it is called, data is removed on
both nodes.

Is it a feature or a bug?

I think it's an oversight. Replication sets were added later than the
TRUNCATE trigger, so the design for the latter does not consider the
former as far as I know.

Ok. May I fill a bug report?

Sure, feel free.

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On 17 September 2015 at 15:17, Sylvain MARECHAL
<marechal.sylvain2@gmail.com> wrote:

Le 15/09/2015 18:56, Alvaro Herrera a écrit :

Sylvain MARECHAL wrote:

[...] The exception is with TRUNCATE: In case it is called, data is
removed on
both nodes.

Is it a feature or a bug?

I think it's an oversight. Replication sets were added later than the
TRUNCATE trigger, so the design for the latter does not consider the
former as far as I know.

Ok. May I fill a bug report?

Please.

It's clearly a bug and will need to be addressed in the next point release.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general