In a recent blog, I described features for PostgreSQL Core that we've been working on
Many people have asked for a similar roadmap for BDR and Postgres-XL. I can confirm that both are under active development and in active use.
XL 9.5 v1.2 is now available, with more updates coming.
XL 9.6 has begun development work, together with active consideration of how to merge parts of that back into Postgres Core and/or minimize the overall set of changes.
BDR 9.4 v0.9.3 is current version. We're continuing to work on BDR 9.4 and will be publishing v1.0 sometime soon
BDR 9.6 is the next objective.
We're also working to merge Logical Replication into PostgreSQL 10 and hopefully the rest of
If you try to update the same data at the same time in multiple locations, your application has a significant problem, period.
That's what I call the physics of multi-master.
How that problem manifests itself is really based upon your choice of technology. Choosing Postgres, Oracle or ProblemoDB won't change the problem, just gives you choices for handling the problem.
If you choose single master, then you get an error because one of the nodes you try to update is read-only and so can't be updated at all.
If you have multiple masters, then you get to choose between an early abort because of serialization errors, or a later difficulty when conflict resolution kicks in. Eager serialization causes massive delays on every transaction, even ones that have no conflict problems. A
and colleagues have been doing, for example. Many if not most of the facilties that make this possible were added for and as part of the BDR project.
My colleagues and I are often asked "when will you (2ndQuadrant) contribute BDR to PostgreSQL?"
This makes an interesting assumption: that we have not already done so. We have. Much of BDR has already been contributed to core PostgreSQL, with more to come. All of BDR is under the PostgreSQL license and could be merged into PostgreSQL at any time if the community wished it (but it doesn't and shouldn't; see below).
It's now quite trivial to implement an extension to add simple multi-master on top of the facilities built-in to PostgreSQL 9.5 if you want to. See the work
Version 0.9.2 of the BDR (Bi-Directional Replication) extension for PosgreSQL has been released.
This is a maintenance release in the current stable 0.9.x series, focused on bug fixes, stability and usability improvements. In particular bdr_init_copy, the pg_basebackup-based node bring-up tool, is significantly improved in this update.
This release also updates the BDR-patched version of PostgreSQL its self to version 9.4.4.
The BDR team has recently introduced support for dynamically adding new nodes to a BDR group from SQL into the current development builds. Now no configuration file changes are required to add nodes and there's no need to restart the existing or newly joining nodes.
This change does not appear in the current 0.8.0 stable release; it'll land in 0.9.0 when that's released, and can be found in the bdr-plugin/next branch in the mean time.
New nodes negotiate with the existing nodes for permission to join. Soon they'll be able to the group without disrupting any DDL locking, global sequence voting, etc.
There's also an easy node removal process so you don't need to modify internal catalog tables and manually remove slots to drop a node anymore.
New node join process
With this change
For a couple of years now a team at 2ndQuadrant led by Andres Freund have been working on adding bi-directional asynchronous multi-master replication support for PostgreSQL. This effort has become known as the BDR project.
We're really excited to see these efforts leading to new PostgreSQL features and have a great deal more still to come.
As a large development project it is neither practical nor desirable to deliver all the changes to PostgreSQL as a single huge patch. That way lies madness and unmaintainable code. It would also be resoundingly rejected by the PostgreSQL community, as it should be.
Instead, BDR has been developed as a series of discrete changes to core PostgreSQL, plus an extension that uses those core changes to implement multi-master
Written by Francesco Canovai
Version 9.4 of PostgreSQL, soon to be released, has many innovations for administrators, including the introduction of support for logical replication, which is the first step towards the integration of multi-master replication into core PostgreSQL. In this two-part article we will show you the main new features for administrators; we begin with logical replication, and describe the following concepts:
Physical replication slots
WAL level "logical"
Logical replication slots
The development of these features is a direct result of the work carried out by 2ndQuadrant, in particular by Andres Freund, the main developer of Bi-Directional Replication (BDR). BDR is an open source
Up until now, reading this blog has kept you up-to-date with the latest developments in PostgreSQL. This time I would like to invite you to meet the team of 2ndQuadrant at the PostgreSQL Conference Europe 2014 which took place in Madrid on October 21st-24th.
As you know, 2ndQuadrant offers 7 days a week, 24 hours a day support to companies all over the globe. As you can well imagine, to be able to provide this non-stop support we have hired world-class experts who have years of experience and are PostgreSQL contributors, developers or committers. To answer your queries without delay, we needed our team to be scattered around the world. Team members who attended the conference came from Japan, Australia, Chile, Ecuador, Argentina, USA, UK, Germany, France, Italy Estonia and the Czech
Streaming replication slots are a pending feature in PostgreSQL 9.4, as part of the logical changeset extraction feature.
What are they for, what do you need to know, what changes?
What are replication slots?
Streaming replication slots are a new facility introduced in PostgreSQL 9.4. They are a persistent record of the state of a replica that is kept on the master server even when the replica is offline and disconnected.
They aren't used for physical replication by default, so you'll only be dealing with them if you enable their use. This post explains what they do, why they're useful for physical replication, and why they're necessary for logical replication.
As part of the ongoing work Andres has been doing on log-streaming logical replication, changeset