l.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Craig Ringer
Sent: Thursday, October 26, 2017 7:24 PM
To: Zhu, Joshua
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] BDR question on dboid conflicts
On 27 October 2017 at 01:15, Zhu, Joshua wrote:
> Database oid is used in both bdr.b
On 27 October 2017 at 01:15, Zhu, Joshua wrote:
> Database oid is used in both bdr.bdr_nodes, as node_dboid, and
> bdr.bdr_connections, as conn_dboid, also used in construction of replication
> slot names.
Correct. However, it's used in conjunction with the sysid and node timeline ID.
> I notice
On 12 October 2017 at 11:03, Andres Freund wrote:
> On 2017-10-12 10:25:43 +0800, Craig Ringer wrote:
>> On 4 October 2017 at 00:21, milist ujang wrote:
>> > On Tue, Oct 3, 2017 at 8:49 PM, Craig Ringer wrote:
>> >>
>> >>
>> >> Can you get stacks please?
>> >>
>> >> Use -g
>> >
>> >
>> > # Event
On 2017-10-12 10:25:43 +0800, Craig Ringer wrote:
> On 4 October 2017 at 00:21, milist ujang wrote:
> > On Tue, Oct 3, 2017 at 8:49 PM, Craig Ringer wrote:
> >>
> >>
> >> Can you get stacks please?
> >>
> >> Use -g
> >
> >
> > # Events: 2K cpu-clock
> > #
> > # Overhead Command Shared Obje
On 4 October 2017 at 00:21, milist ujang wrote:
> On Tue, Oct 3, 2017 at 8:49 PM, Craig Ringer wrote:
>>
>>
>> Can you get stacks please?
>>
>> Use -g
>
>
> # Events: 2K cpu-clock
> #
> # Overhead Command Shared ObjectSymbol
> # .
Hi Craig,
Anyway, this OS is guess OS in vmware (vsphere).
Thank for your response and help.
On Tue, Oct 3, 2017 at 8:49 PM, Craig Ringer wrote:
>
>
> Can you get stacks please?
>
> Use -g
>
# Events: 2K cpu-clock
#
# Overhead Command Shared ObjectSymbol
# ...
On 3 October 2017 at 19:45, milist ujang wrote:
> Hi all,
>
> I've an environment 9.4 + bdr:
> PostgreSQL 9.4.4
>
You're on a pretty old postgres-bdr. Update. You're missing a lot of fixes
from mainline.
> This is consolidation databases, in this machine there are around 250+ wal
> sender pro
Hi Craig,
So, is it safe to drop those list from this query output?
select riname from pg_replication_identifier where riname not in
(select external_id from pg_replication_identifier_progress);
I cannot read pg_get_replication_identifier_progress function, is it likely
c function?
On Fri, S
On 15 September 2017 at 11:46, milist ujang wrote:
> Hi Craig,
>
> Thanks again for pointing to inactive replication slot.
> After inactive replication slot been dropped, the relfrozenxid now moving.
>
> I wonder if replication identifier will have some issue if left
> un-chained? since at other
Hi Craig,
Thanks again for pointing to inactive replication slot.
After inactive replication slot been dropped, the relfrozenxid now moving.
I wonder if replication identifier will have some issue if left
un-chained? since at other side there are inactive replication identifier.
On Fri, Sep 1
On 14 September 2017 at 13:35, milist ujang wrote:
> HI list,
>
> I have a database with bdr environment which keep alerting these messages
> in log file:
>
> HINT: Close open transactions soon to avoid wraparound problems.
> WARNING: oldest xmin is far in the past
>
Do you have any idle/old r
On 11 September 2017 at 09:32, milist ujang wrote:
> Hi all,
>
> Based on the docs and look at the processes, it seems 1 wal sender on each
> node per group.
>
> If there is scenario of consolidating many databases (say hundreds) into 1
> database (in this central cluster there are hundreds wal s
On 7 September 2017 at 21:16, milist ujang wrote:
> Hi Craig,
>
> On Wed, Sep 6, 2017 at 4:07 PM, Craig Ringer
> wrote:
>
>>
>> You could drop and re-create the replication slot, I guess. But your
>> nodes would be hopelessly out of sync and need manual resync (with data
>> replication disabled)
Hi Craig,
On Wed, Sep 6, 2017 at 4:07 PM, Craig Ringer wrote:
>
> You could drop and re-create the replication slot, I guess. But your nodes
> would be hopelessly out of sync and need manual resync (with data
> replication disabled) of one node vs another.
>
Thanks for pointing to replication s
On 6 September 2017 at 08:47, milist ujang wrote:
> Hi Craig
>
> On Wed, Sep 6, 2017 at 7:21 AM, Craig Ringer
> wrote:
>>
>>
>> BDR can, see bdr.skip_changes_upto .
>>
>> Unluckily my bdr is 0.9.3
>
>
>> But PostgreSQL's logical decoding requires a contiguous WAL stream to
>> maintain a valid ca
Hi Craig
On Wed, Sep 6, 2017 at 7:21 AM, Craig Ringer wrote:
>
>
> BDR can, see bdr.skip_changes_upto .
>
> Unluckily my bdr is 0.9.3
> But PostgreSQL's logical decoding requires a contiguous WAL stream to
> maintain a valid catalog_xmin and restart_lsn, so it'll still fail to
> advance. So you
On 6 September 2017 at 01:52, milist ujang wrote:
> Hi all,
>
> due to space issue and high volume transaction, some wal segments removed
> from pg_xlog on bdr environment.
>
What, you deleted them?
> I had played streams and goldengate (oracle product) , that at capture
> side we can move for
neral
Subject: Re: [GENERAL] BDR replication port
That's weird. Another idea: Do changes on that server get replicated to the
other servers? I'm not sure if incomming connections are used to receive WAL or
to send it.
Regards,
Alvaro Aguayo
Jefe de Operaciones
Open Comb Systems E.I.R.L.
252 / (+51) 995540103 | RPC: (+51)
954183248
Website: www.ocs.pe
- Original Message -
From: "Zhu, Joshua"
To: "Alvaro Aguayo Garcia-Rada"
Cc: "PostgreSql-general"
Sent: Friday, 25 August, 2017 18:35:21
Subject: RE: [GENERAL] BDR replication port
Thought about t
: [GENERAL] BDR replication port
Just a guess: How did you blocked the port? Depending on that, you could be
blocking only new connections, but connections already established would
continue to transmit data; remember BDR only reconnects when connection is lost.
Alvaro Aguayo
Jefe de Operaciones
Just a guess: How did you blocked the port? Depending on that, you could be
blocking only new connections, but connections already established would
continue to transmit data; remember BDR only reconnects when connection is lost.
Alvaro Aguayo
Jefe de Operaciones
Open Comb Systems E.I.R.L.
Ofic
On 14 July 2017 at 00:09, Zhu, Joshua wrote:
>
>
> Found these log entries from one of the other node:
>
>
>
> t=2017-07-13 08:35:34 PDT p=27292 a=DEBUG: 0: found valid replication
> identifier 15
>
> t=2017-07-13 08:35:34 PDT p=27292 a=LOCATION:
> bdr_establish_connection_and_slot, bdr.c:60
Ringer [mailto:cr...@2ndquadrant.com]
Sent: Wednesday, July 12, 2017 11:59 PM
To: Zhu, Joshua
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] BDR node removal and rejoin
On 13 July 2017 at 01:56, Zhu, Joshua
mailto:j...@vormetric.com>> wrote:
Thanks for the clarification.
Looks lik
On 13 July 2017 at 01:56, Zhu, Joshua wrote:
> Thanks for the clarification.
>
>
>
> Looks like I am running into a different issue: while trying to pin down
> precisely the steps (and the order in which to perform them) needed to
> remove/rejoin a node, the removal/rejoining exercise was repeate
[mailto:cr...@2ndquadrant.com]
Sent: Wednesday, July 12, 2017 1:59 AM
To: Zhu, Joshua
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] BDR node removal and rejoin
On 11 July 2017 at 05:49, Zhu, Joshua
mailto:j...@vormetric.com>> wrote:
An update… after manually removing the record for
On 11 July 2017 at 05:49, Zhu, Joshua wrote:
> An update… after manually removing the record for ‘node4’ from
> bdr.bdr_nodes, corresponding record in bdr.bdr_connections, and associated
> replication slot (with pg_drop_replication_slot), rejoining was successful.
>
>
>
> I was under the impressi
An update... after manually removing the record for 'node4' from bdr.bdr_nodes,
corresponding record in bdr.bdr_connections, and associated replication slot
(with pg_drop_replication_slot), rejoining was successful.
I was under the impression that there is no need to perform manual cleanup
befo
> However if I perform any INSERT, UPDATE or DELETE operations on
> DB2 and these changes propagate over to DB1 via BDR I do not see DB1 firing
> any triggers. Is this intended behavior?
Yes.
> My current understanding is that
> BDR is unable to invoke Postgres triggers as it operates on the row
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 Alv
Hi.
It's not like BDR is unable to replicate triggers across the cluster: BDR is
not intended to do so.
BDR replicates everything that happens inside a transaction; that includes both
SQL run directly from the application, as well as changes made by triggers and
extensions. As the changes are
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 no problem. Howeve
On 12 October 2016 at 00:55, Sylvain MARECHAL
wrote:
> Le 07/10/2016 à 23:54, Natan Abolafya a écrit :
>
> 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
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 ti
On 31 August 2016 at 22:38, Salvatore Tomaselli
wrote:
> Hello,
>
> I have been looking around in the documentation and I didn't find anything,
> so I wonder if there is support in bdr for having transactions that happen
> while the global lock is acquired and get replicated everywhere before th
El 20/07/16 a las 20:06, Jonathan Eastgate escribió:
>
> I assume that once BDR is enabled on a database that any additional
> schemas added post config are automatically included in BDR replication?
All DDLs (CREATE SCHEMA ...) will be replicated to the other nodes, but
if you are asking if the
Thanks guys.
Very helpful - I was thinking we may need to look at moving to schemas
instead of individual db's.
I assume that once BDR is enabled on a database that any additional schemas
added post config are automatically included in BDR replication?
And so you see any issues having potentiall
On 20 July 2016 at 13:22, Jonathan Eastgate
wrote:
> Hi everyone.
>
> We've been testing BDR on and off for the last 2 years and are keen to
> start looking at implementing it in production as it seems 0.93 has
> resolved most of the issues we faced with it in the early days.
>
> However there is
Hello. BDR works on a per-database basis, so there's nothing like what you are
looking for. However, if you initialize a BDR custer with bdr_init_copy, you
will get all existing databases added to replication. Then, as part of the
creation of new databases, you can use bdr_group_join function, w
umar"
Cc: "PostgreSql-general"
Sent: Monday, 13 June, 2016 07:13:09
Subject: Re: [GENERAL] BDR
http://bdr-project.org/docs/next/logical-vs-physical.html
"It (BDR) has significant advantages - and some disadvantages - when
compared to PostgreSQL's older physical (block-based)
http://bdr-project.org/docs/next/logical-vs-physical.html
"It (BDR) has significant advantages - and some disadvantages - when
compared to PostgreSQL's older physical (block-based) streaming or
archive-based replication with warm or hot standby"
What exactly is block based? Changes are recorded i
On 11 June 2016 at 02:12, Rakesh Kumar wrote:
> Sorry if this question was asked before. As I understand currently
> BDR does not support the replicating nodes to run different major
> versions, like
> 9.4 <-> 9.5.
>
> Is this in the works?
>
Not with BDR between 9.4 and 9.5, no, as there will
On 11 June 2016 at 02:26, David G. Johnston
wrote:
> On Fri, Jun 10, 2016 at 2:12 PM, Rakesh Kumar
> wrote:
>
>> Sorry if this question was asked before. As I understand currently
>> BDR does not support the replicating nodes to run different major
>> versions, like
>> 9.4 <-> 9.5.
>>
>> Is thi
> This seems relevant...
>
> http://bdr-project.org/docs/stable/logical-vs-physical.html
thanks. very useful.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Fri, Jun 10, 2016 at 2:12 PM, Rakesh Kumar
wrote:
> Sorry if this question was asked before. As I understand currently
> BDR does not support the replicating nodes to run different major
> versions, like
> 9.4 <-> 9.5.
>
> Is this in the works?
>
This seems relevant...
http://bdr-project
Thanks a lot Martin for your replies.
On Sun, May 29, 2016 at 11:50 PM, Martín Marqués
wrote:
> Hi,
>
> El 29/05/16 a las 06:01, Nikhil escribió:
> >
> > *Nik>> skip_ddl_locking is set to True in my configuration. As this
> > was preventing single*
> >
> > *node from doing DDL operatio
Hi,
El 29/05/16 a las 06:01, Nikhil escribió:
>
> *Nik>> skip_ddl_locking is set to True in my configuration. As this
> was preventing single*
>
> *node from doing DDL operation (if one is down majority is not there
> for doing DDL on available node)*
Well, you have to be prepared to
Please see my replies inline.
On Sat, May 28, 2016 at 8:08 PM, Martín Marqués
wrote:
> El 28/05/16 a las 08:57, Nikhil escribió:
> > Once the node which was down is brought back the replication slot is not
> > turned active. The reason being replication slot is trying to create a
> > partition t
El 28/05/16 a las 08:57, Nikhil escribió:
> Once the node which was down is brought back the replication slot is not
> turned active. The reason being replication slot is trying to create a
> partition table which already exists. Because of this error replication
> slot is stuck in inactive mode. I
El 28/05/16 a las 08:57, Nikhil escribió:
> Once the node which was down is brought back the replication slot is not
> turned active. The reason being replication slot is trying to create a
> partition table which already exists. Because of this error replication
> slot is stuck in inactive mode. I
Once the node which was down is brought back the replication slot is not
turned active. The reason being replication slot is trying to create a
partition table which already exists. Because of this error replication
slot is stuck in inactive mode. Is there any way to ignore this error?
On 28-May-20
El 27/05/16 a las 06:33, Nikhil escribió:
> Hello,
>
>
> I have a BDR setup with two nodes. If I bring one node down i am seeing that
> the replication slot is becoming inactive with below error.
If you take down one of the nodes of a BDR mesh, the replication slots
from each of the upstream nod
On 28 April 2016 at 02:47, Will McCormick wrote:
> So if I wanted to extend a column from 100 characters to 255 characters is
> this permitted? The fact that I'm not making a change and the BDR kicked me
> out makes me skeptical.
>
Off the top of my head I'm not sure and would need to test. Ther
If you change the length of a character varying, it should work. I'm almost
sure I have done that before on my BDR cluster.
It may work as long as it does not require a full table rewrite. I think, the
length change for a character varying won't need a full table rewrite, as the
length is only
So if I wanted to extend a column from 100 characters to 255 characters is
this permitted? The fact that I'm not making a change and the BDR kicked me
out makes me skeptical.
On Wed, Apr 27, 2016 at 11:56 AM, Craig Ringer
wrote:
> On 27 April 2016 at 23:43, Alvaro Aguayo Garcia-Rada <
> aagu...@
On 27 April 2016 at 23:43, Alvaro Aguayo Garcia-Rada <
aagu...@opensysperu.com> wrote:
> Based on my experience, I can say BDR does not performs pre-DDL checks.
> For example, if you try to CREATE TABLE with the name of an existing table,
> BDR will acquire lock anyway, and then will fail when exe
Based on my experience, I can say BDR does not performs pre-DDL checks. For
example, if you try to CREATE TABLE with the name of an existing table, BDR
will acquire lock anyway, and then will fail when executing the DDL statement
on the first node, because the table already exists.
In your case
I guess the only viable option would be to the check explicitly ourselves.
On Wed, Apr 27, 2016 at 11:25 AM, Will McCormick
wrote:
> But this is the exact column definition that exists on the table when I
> execute the statement
>
> It's like it does not check the pre-existing state of the
But this is the exact column definition that exists on the table when I
execute the statement
It's like it does not check the pre-existing state of the column. Our code
is expecting a column already exists error but this error predicates that.
On Wed, Apr 27, 2016 at 10:21 AM, Adrian Klaver
On 04/27/2016 07:13 AM, Will McCormick wrote:
Why does this not work? From what I read only default values should
cause issue. I'm on release 9.4.4:
bms=# ALTER TABLE trap ALTER COLUMN trap_timestamp TYPE TIMESTAMP WITH
TIME ZONE;
ERROR: ALTER TABLE ... ALTER COLUMN TYPE may only affect UNLOGG
Hi All,
And sorry about that damn thumb pad! Premature send!
On Wed, Apr 27, 2016 at 10:15 AM, Adrian Klaver
wrote:
> On 04/27/2016 07:11 AM, Will McCormick wrote:
>
>> Why does this not work:
>>
>>
> Because it is NULL :)?
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
On 04/27/2016 07:11 AM, Will McCormick wrote:
Why does this not work:
Because it is NULL :)?
--
Adrian Klaver
adrian.kla...@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-genera
On interface down:
--
<10.102.31.213(27599)postgres13082016-04-19 06:31:36
GMTprocess_journal%LOG: terminating walsender process due to replication
timeout
Once interface is brought back
425906 <12692016-04-19 08:32:58 GMT%LOG: starting
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 interface slots are not t
Hello,
What do you see on each node's log after enablibg interfaces?
Regards,
Alvaro Aguayo
Jefe de Operaciones
Open Comb Systems E.I.R.L.
Oficina: (+51-1) 3377813 | RPM: #034252 / (+51) 995540103 | RPC: (+51)
954183248
Website: www.ocs.pe
Sent from my Sony Xperia™ smartphone
Nikhil wr
"volga629"
Cc: "pgsql-general" , "John R Pierce"
Sent: Thursday, 31 March, 2016 02:41:17
Subject: Re: [GENERAL] bdr replication
We are overlaping mails :P
What I don't understand is the need of a shared storage in this case. It would
be a lot better to h
ia-Rada"
To: "volga629"
Cc: "pgsql-general" , "John R Pierce"
Sent: Thursday, 31 March, 2016 02:41:17
Subject: Re: [GENERAL] bdr replication
We are overlaping mails :P
What I don't understand is the need of a shared storage in this case. It would
On 3/30/2016 10:41 PM, Alvaro Aguayo Garcia-Rada wrote:
What I don't understand is the need of a shared storage in this case. It would
be a lot better to have the data folder inside each server virtual disk to
avoid troubles with the shared storage; I really see no reason for such
configuratio
M: #034252 / (+51) 995540103 | RPC: (+51)
954183248
Website: www.ocs.pe
- Original Message -
From: "Slava Bendersky"
To: "Alvaro Aguayo Garcia-Rada"
Cc: "pgsql-general" , "John R Pierce"
Sent: Thursday, 31 March, 2016 12:28:09 AM
Subject: Re: [GENER
question how to restore BDR replication
correctly.
volga629
From: "Alvaro Aguayo Garcia-Rada"
To: "volga629"
Cc: "pgsql-general" , "John R Pierce"
Sent: Thursday, 31 March, 2016 02:19:42
Subject: Re: [GENERAL] bdr replication
What's the purpose o
I.R.L.
Oficina: (+51-1) 3377813 | RPM: #034252 / (+51) 995540103 | RPC: (+51)
954183248
Website: www.ocs.pe
- Original Message -
From: "Slava Bendersky"
To: "John R Pierce"
Cc: "pgsql-general"
Sent: Wednesday, 30 March, 2016 10:57:13 PM
Subject: Re: [GENERA
e"
Cc: "pgsql-general"
Sent: Thursday, 31 March, 2016 00:57:13
Subject: Re: [GENERAL] bdr replication
In my case only virtual hosts are use share storage (feed from glusterfs), but
actual virtual machines have own separate disks and all PostgreSQL run on
separate data director
0:34:55
Subject: Re: [GENERAL] bdr replication
On 3/30/2016 8:09 PM, Slava Bendersky wrote:
> Is any share storage technology recommended for PostgreSQL in virtual
> environment ?
> Ok what I will do is going take backups, shutdown both virtual servers
> and place all vm use loca
On 3/30/2016 8:09 PM, Slava Bendersky wrote:
Is any share storage technology recommended for PostgreSQL in virtual
environment ?
Ok what I will do is going take backups, shutdown both virtual servers
and place all vm use local disk on server only.
'share storage technology'... um.thats
Cc: "pgsql-general"
Sent: Wednesday, 30 March, 2016 23:57:28
Subject: Re: [GENERAL] bdr replication
On 31 March 2016 at 10:43, Slava Bendersky < volga...@skillsearch.ca > wrote:
Hello Craig,
The current setup is two server which run libvirt and for storage which run
gluste
On 31 March 2016 at 10:43, Slava Bendersky wrote:
> Hello Craig,
> The current setup is two server which run libvirt and for storage which
> run glusterfs (storage server feed two virtual servers). Right now is no
> fencing in place. Each of the nodes have one PostgreSQL vm with bdr.
>
That's
9"
Cc: "pgsql-general"
Sent: Wednesday, 30 March, 2016 23:20:49
Subject: Re: [GENERAL] bdr replication
On 31 March 2016 at 09:38, Slava Bendersky < volga...@skillsearch.ca > wrote:
Hello Everyone,
I am looking for suggestion how to recover bdr replication.
The shor
On 31 March 2016 at 09:38, Slava Bendersky wrote:
> Hello Everyone,
> I am looking for suggestion how to recover bdr replication.
> The short story we have 2 virtual nodes with share storage.
>
Can you describe the "shared storage" setup in more detail?
In general, with PostgreSQL "shared stora
On 3/14/2016 2:43 PM, Roland van Laar wrote:
However my instances are not on the same server and I attempted to
simply add a host=(the ip) but that failed.
There are a couple of other factors:
- is postgres running on an external available ip?
- is there a replication user with a password?
3:
On 15 March 2016 at 05:17, Dustin Kempter
wrote:
> However my instances are not on the same server and I attempted to simply
> add a host=(the ip) but that failed. Please help
>
Review the logs on both hosts to see any errors during setup.
Note that you will need to drop and re-create the datab
Also, what did you run exactly (sanitized of course).
On March 14, 2016 5:38:19 PM EDT, John R Pierce wrote:
>On 3/14/2016 2:17 PM, Dustin Kempter wrote:
>> However my instances are not on the same server and I attempted to
>> simply add a host=(the ip) but that failed. Please help
>
>did you g
On 14-03-16 22:17, Dustin Kempter wrote:
Hello all, I am attempting to set up BDR between 2 separate nodes. I
have been following the guide and got to here
http://bdr-project.org/docs/0.9.0/quickstart-enabling.html
I am now stuck on this section
"Then you run a function that identifies a BDR g
On 3/14/2016 2:17 PM, Dustin Kempter wrote:
However my instances are not on the same server and I attempted to
simply add a host=(the ip) but that failed. Please help
did you get an error? if so what error, exactly?
--
john r pierce, recycling bits in santa cruz
--
Sent via pgsql-gener
On 3 March 2016 at 07:54, cchee-ob wrote:
> I queried pg_replication_slots after I removed an BDR node and I noticed a
> slot_name that isn't in bdr.bdr_node_slots. And active is 'f' and it has
> been retaining bytes. Should I be concerned and is there a way to remove
> it. I do still have one
On 2 February 2016 at 05:07, cchee-ob wrote:
> I noticed that the BDR replication continually trying to replay a ddl
> statement that has a syntax error. Is there anything that can be done to
> skip this statement or do I need to rebuild the replicated node?
That's a DDL deparse bug. Ouch. Not
On Mon, Feb 1, 2016 at 12:24 AM, John R Pierce wrote:
> On 1/29/2016 3:00 AM, Kaushal Shriyan wrote:
>
>>
>> Do i need to install any BDR specific package to enable it in postgresql
>> 9.5 version. While reading
>> http://bdr-project.org/docs/0.9.0/install-requirements.html i assumed
>> that it i
On 1/29/2016 3:00 AM, Kaushal Shriyan wrote:
Do i need to install any BDR specific package to enable it in
postgresql 9.5 version. While reading
http://bdr-project.org/docs/0.9.0/install-requirements.html i assumed
that it is available in 9.5 version by default without using any
patches. Ple
BDR extension is not available in 9.5. You need to install it separately.
- Sachin
On 29 Jan 2016 4:31 p.m., "Kaushal Shriyan"
wrote:
> Hi,
>
> I am following http://bdr-project.org/docs/stable/index.html to setup BDR
> for postgresql version 9.5 as per
>
> [root@ip-172-31-1-17 9.5]# cat /etc/re
On 29 January 2016 at 18:27, Nikhil wrote:
> Is there any way to specify priority for replication. or any parameter
> which guarantees something about replication (speed at which it replicates,
> number of minimum replicas to write).
>
Not yet. Not in core PostgreSQL streaming replication, nor
On 1/29/2016 2:27 AM, Nikhil wrote:
Is there any way to specify priority for replication. or any parameter
which guarantees something about replication (speed at which it
replicates, number of minimum replicas to write).
Does BDR has a configuration for differentiated services in
replicatio
On 22 January 2016 at 04:24, Merlin Moncure wrote:
> On Wed, Jan 20, 2016 at 12:52 PM, Vik Fearing wrote:
> > On 01/20/2016 11:41 AM, Nikhil wrote:
> >> Hello All,
> >>
> >>
> >> What is the timeline for BDR with postgres 9.5 released version.
> >
> > Currently there are no plans for BDR with 9.
On Wed, Jan 20, 2016 at 12:52 PM, Vik Fearing wrote:
> On 01/20/2016 11:41 AM, Nikhil wrote:
>> Hello All,
>>
>>
>> What is the timeline for BDR with postgres 9.5 released version.
>
> Currently there are no plans for BDR with 9.5.
> https://github.com/2ndQuadrant/bdr/issues/157#issuecomment-17240
On 01/20/2016 11:41 AM, Nikhil wrote:
> Hello All,
>
>
> What is the timeline for BDR with postgres 9.5 released version.
Currently there are no plans for BDR with 9.5.
https://github.com/2ndQuadrant/bdr/issues/157#issuecomment-172402366
--
Vik Fearing +
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).
On 11 January 2016 at 18:55, Oleksii Kliukin wrote:
> We are evaluating BDR for a multi-master cross-datacenter replication,
> with 2 masters actually communicating across datacenter, supplemented by a
> local in-datacenter replicas to provide HA.
>
This is strongly desirable ... but not curren
On 13 January 2016 at 21:45, Sylvain MARECHAL
wrote:
> The problem is that the (1) DDL request will wait indefinitely, meaning
> all transactions will continue to fail until the DDL operation is manually
> aborted (for example, doing CTRL C in psql to abort the "CREATE TABLE").
>
Correct, and b
On 13-01-16 17:48, LOUBRADOU, Rémy wrote:
Hi,
I have the same issue. It was working fine a month ago. I wrote a
cookbook with chef to install BDR a month ago since then I did not
change the cookbook but now I got this error.
This seem to be the heart of the issue:
Removing obsolete dictiona
On 4 January 2016 at 20:09, Riley Berton wrote:
> The conflict on the "thingy" table has resulted in node2 winning based
> on last_update wins default resolution. However, both inserts have
> applied. My expectation is that the entire TX applies or does not
> apply. This expectation is clearl
Craig Ringer writes:
> On 5 January 2016 at 04:09, Riley Berton wrote:
>
>>
>> The conflict on the "thingy" table has resulted in node2 winning based
>> on last_update wins default resolution. However, both inserts have
>> applied. My expectation is that the entire TX applies or does not
>> ap
On 5 January 2016 at 04:09, Riley Berton wrote:
>
> The conflict on the "thingy" table has resulted in node2 winning based
> on last_update wins default resolution. However, both inserts have
> applied. My expectation is that the entire TX applies or does not
> apply. This expectation is clear
Em 05/01/2016 11:42, Riley Berton escreveu:
Edson Richter writes:
BTW, I'm also looking for a "synchronous multi-master" solution... If
you find one, please share :-)
The only solution I've found so far is a middleware that is close, the
C-Jdbc/Sequoia, which seems not being actively maintaine
1 - 100 of 295 matches
Mail list logo
