The BDR and pglogical apt repository GnuPG signing keys have been renewed.
Users should re-import the existing keys. You can verify that it's still the same key as referenced in the documentation, just with a later expiry date.
wget --quiet -O - http://packages.2ndquadrant.com/bdr/apt/AA7A6805.asc | sudo apt-key add -
sudo apt-key finger AA7A6805 | grep -A2 -B3 BDR
Now check the fingerprint printed by the second command to verify it's the same as this output:
pub 2048R/AA7A6805 2015-03-24 [expires: 2019-03-23]
Key fingerprint = 855A F5C7 B897 6564 17FA 73D6 5D94 1908 AA7A 6805
uid BDR Apt Signing Key for 2ndQuadrant
sub 2048R/739C93DD 2015-03-24 [expires: 2019-03-23]
and if it is, run:
sudo apt-get update
BDR is both a patch to PostgreSQL core and an extension on top of PostgreSQL core. How did that come about, and what's it's future?
Development of BDR was initiated around the time PostgreSQL 9.2 was in development. Arguably earlier if you count things like the extension mechanism. The goal of BDR is, and has always been, to add necessary features to core PostgreSQL to perform asynchronous loosely-coupled multi-master logical replication.
BDR improvements to core PostgreSQL
Since it's such a large set of changes it was necessary to structure development as a series of discrete features. A natural dividing line was "things that require changes to the core PostgreSQL code" vs "things that can be done in an extension". So the code was structured accordingly, making BDR a set of patches
I'm pleased to say that Postgres-BDR is on its way to PostgreSQL 9.6, and even better, it works without a patched PostgreSQL.
BDR has always been an extension, but on 9.4 it required a heavily patched PostgreSQL, one that isn't fully on-disk-format compatible with stock community PostgreSQL 9.4. The goal all along has been to allow it to run as an extension on an unmodified PostgreSQL ... and now we're there.
The years of effort we at 2ndQuadrant have put into getting the series of patches from BDR into PostgreSQL core have paid off. As of PostgreSQL 9.6, the only major patch that Postgres-BDR on 9.4 has that PostgreSQL core doesn't, is the sequence access method patch that powers global sequences.
This means that Postgres-BDR on 9.6 will not support global sequences, at least not
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
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
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