Thread: BDR truncate and replication sets
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 am not sure it is related with
https://github.com/2ndQuadrant/bdr/issues/93)
Is there a workaround?
(deleting the truncate trigger seems to work, but I am sure it is safe
to do it)
Thanks and Regards,
--
Sylvain
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
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
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
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