Re: [GENERAL] BDR: Can a node live alone after being detached

Le 26/06/2015 03:26, Craig Ringer a écrit : [...] Sorry to bother again about that, but what about the detached node cleanup best practice? Suppose I have 2 nodes, 'node1' and 'node2'. So I am OK to call bdr_part_by_node_names('node2') on node1 to detach node2. But then, is it safe to call

Re: [GENERAL] BDR: Can a node live alone after being detached

You shouldn't part a node from its self. The next revision will prevent this with an error. Ok, this was not clear for me. Or anyone else, hence the coming docs and code changes. Sorry to bother again about that, but what about the detached node cleanup best practice? Suppose I have

[GENERAL] BDR: Can a node live alone after being detached

Hello all, Is it possible to completely detach a node so that it can live alone, in particular that DDL are again possible on that node? I tried with a simple node without success: postgres=# create database test template template0; CREATE DATABASE postgres=# \c test You are now connected to

Re: [GENERAL] BDR: Can a node live alone after being detached

Hi Craig, Thanks for your response. Le 16/06/2015 03:58, Craig Ringer a écrit : On 15 June 2015 at 17:19, Sylvain MARECHAL marechal.sylva...@gmail.com wrote: Is it possible to completely detach a node so that it can live alone Yes. On a different node to the one you want to remove

[GENERAL] Getting the value of the old_tuple using the test_decoding extension and BDR

Hello all, I am playing with the test_decoding extension to be notified on database changes in a couple of databases replicated with BDR. What I can see is that new values are present, and also old key when the modification concerns the primary key. But the other old values do not seem to be

[GENERAL] Re: Getting the value of the old_tuple using the test_decoding extension and BDR

2015-07-02 16:11 GMT+02:00 Sylvain MARECHAL marechal.sylva...@gmail.com: Hello all, [...] What I can see is that new values are present, and also old key when the modification concerns the primary key. But the other old values do not seem to be accessible. Is it a limitation

Re: [GENERAL] BDR setup - bdr_node_join_wait_for_ready()

Hello all, Le 31/08/2015 02:25, Martín Marqués a écrit : BTW, why don't you the physical join procedure with bdr_init_copy to join nodes? Are there known problems in the SQL interface ? Thank you, Sylvain -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes

[GENERAL] 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

Re: [GENERAL] BDR truncate and replication sets

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

Re: [GENERAL] bdr manual cleanup required

No warning or error entries in the log file on all nodes but the replication works only from the first node to the second and third nodes and from the second node to the third node. -Selim -------- *From:* Sylvain Marechal [mare

Re: [GENERAL] bdr manual cleanup required

Did you try this : https://github.com/2ndQuadrant/bdr/issues/127 : <<< BEGIN; SET LOCAL bdr.skip_ddl_locking = on; SET LOCAL bdr.permit_unsafe_ddl_commands = on; SET LOCAL bdr.skip_ddl_replication = on; SECURITY LABEL FOR bdr ON DATABASE mydb IS NULL; DELETE FROM bdr.bdr_connections; DELETE FROM

Re: [GENERAL] bdr manual cleanup required

Le 09/12/2015 05:18, Craig Ringer a écrit : Are you adding more than one node at once? BDR isn't currently smart enough to handle that. Make sure to wait until one node is fully synced up before adding another. ​ In other words, one shall not attemp to add a new node if the other nodes are

Re: [GENERAL] BDR: ALTER statement hanging

Le 04/12/2015 18:59, Andreas Kretschmer a écrit : I think, the state 'i' is the main reason for your problem, because of: "i- Joining: The node is doing initial slot creation or an initial dump and load". But i can't tell you why this nodes are in this state. Regards, Andreas Did-you

[GENERAL] [BDR] Best practice to automatically abort a DDL operation when one node is down

Hello all, I am using BDR with two nodes 1 and 2. If I issue a DDL operation in node 1 when node 2 is down, for example: CREATE TABLE test (i int PRIMARY KEY); (1) all other transactions fail with the following error: Database is locked against DDL operations The problem is that the (1)

Re: [GENERAL] [BDR] Best practice to automatically abort a DDL operation when one node is down

What is the best practice to make sure the DDL operation will fail, possibly after a timeout, if one of the node is down? statement_timeout Ok. Thank-you for pointing this. I have just tried it, and this work great even for nodes that are not properly power off (plug removed).

[GENERAL] Re: [BDR] Best practice to automatically abort a DDL operation when one node is down

I am using BDR with two nodes 1 and 2. If I issue a DDL operation in node 1 when node 2 is down, for example: CREATE TABLE test (i int PRIMARY KEY); (1) all other transactions fail with the following error: Database is locked against DDL operations The problem is that the (1) DDL request

Re: [GENERAL] BDR replication slots

2016-04-19 6:51 GMT+02:00 Nikhil : > Hello, > > I have a 2 node BDR group and replication is happening properly. if i > bring down one of the node's interface, after sometime the replication > slots are becoming inactive (pg_replication_slots view). Then if i bring > back

Re: [GENERAL] A simple extension immitating pg_notify

I understand that: 1) you like to use postgres as a "bus" to transfer messages between connected clients; 2) only one database server is concerned (no redundancy at all); 3) it is the client code (perl, php ...) that send the notification (ie, notifications are not sent by triggers for example)

Re: [GENERAL] BDR problem rejoining node

2017-02-11 1:34 GMT+01:00 Tanner Kerr : > I have two databases being replicated across three nodes with bdr. The > third node filled up and crashed. I removed this node from the group > successfully, but now I'm having trouble rejoining it. I'm able to re-join > the one database

[GENERAL] BDR: Recover from "FATAL: mismatch in worker state" without restarting postgres

Hello all, After uninstalling a BDR node, it becomes not possible to join it again. The following log appears in loop: <<< 2016-08-25 10:17:08 [ll101] postgres info [11709]: [14620-1] LOG: starting background worker process "bdr (6287997142852742670,1,19526,)->bdr (6223672436788445259,2,"

[GENERAL] Monitor pg_xlog size via SQL with postgres 9.4

Hello all, is there a way to monitor the size of the pg_xlog directory in SQL? The goal is to monitor the pg_xlog file without ressorting to a 'du' like solution that needs a direct access to the machine. I know I can get the retained size for existing replication slots segment in case there are

Re: [GENERAL] Monitor pg_xlog size via SQL with postgres 9.4

​ 2016-09-22 16:05 GMT+02:00 hubert depesz lubaczewski <dep...@depesz.com>: > On Thu, Sep 22, 2016 at 02:23:20PM +0200, Sylvain Marechal wrote: > > is there a way to monitor the size of the pg_xlog directory in SQL? The > > Assuming you have superuser privileges, it

Re: [GENERAL] BDR: changing dsn on a running node

Le 07/10/2016 à 23:54, Natan Abolafya a écrit : Hi Is it possible to change the dsn connection string of a node without leaving the group? I couldn’t find the related documentation unfortunately. We’re using BDR in a dynamic environment where the hostname/ip of a node may be changed any

Re: [GENERAL] Best way to alter a foreign constraint

2017-03-18 20:40 GMT+01:00 Adrian Klaver <adrian.kla...@aklaver.com>: > On 03/18/2017 12:05 PM, Sylvain Marechal wrote: > >> Hello all, >> >> Some of my tables were badly designed and have 2 indexes, like the >> following example (lots of tables have same

Re: [GENERAL] Best way to alter a foreign constraint

2017-03-19 17:55 GMT+01:00 Adrian Klaver <adrian.kla...@aklaver.com>: > On 03/19/2017 01:54 AM, Sylvain Marechal wrote: > >> >> >> 2017-03-18 20:40 GMT+01:00 Adrian Klaver <adrian.kla...@aklaver.com >> <mailto:adrian.kla...@aklaver.com>>: >>

[GENERAL] Best way to alter a foreign constraint

Hello all, Some of my tables were badly designed and have 2 indexes, like the following example (lots of tables have same problem): <<< postgres=# \d test1 Table "public.test1" Column | Type | Modifiers +-+--- t1 | integer | not null Indexes:

Re: [GENERAL] Best way to alter a foreign constraint

Le 19/03/2017 à 09:54, Sylvain Marechal a écrit : 2017-03-18 20:40 GMT+01:00 Adrian Klaver <adrian.kla...@aklaver.com <mailto:adrian.kla...@aklaver.com>>: On 03/18/2017 12:05 PM, Sylvain Marechal wrote: Hello all, Some of my tables were badly designed and ha

Re: [GENERAL] BDR replication and table triggers

Why not using the logical decoding feature: https://www.postgresql.org/docs/9.4/static/logicaldecoding-example.html On both sides, you would have a process that regularly decodes the stream and emits notifications for event in tables you are insterested in. Sylvain 2017-05-02 18:18 GMT+02:00