Monday, June 26

BDR is coming to PostgreSQL 9.6

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 the same way they exist in 9.4. The 9.6 version will incorporate a different approach to handling sequences on distributed systems, and in the process address some issues that arose when using global sequences in production.

Since Postgres-BDR on 9.6 is now passing regression tests (except for global sequences), I expect to have an alpha release out not long after the release of PostgreSQL 9.6 itself. Keep an eye out!

There’s also a pglogical 1.2.0 update coming to coincide with the release of PostgreSQL 9.6.

At the same time, Petr has submitted another revision of logical replication for core PostgreSQL to the 10.0 development series.

Along with updating Postgres-BDR in concurrence with 9.6, there is work in progress to enhance Postgres-BDR’s HA capabilities. I’ll have more to say on that in an upcoming post.

We’ve been busy here at 2ndQuadrant.

33 Comments

  • Rolphy Reyes

    Hi.

    Excuseme my ignorance.

    Are you telling that Postgres 9.6 will include this feature built-in? Not a fork version?

    Sorry for my bad english.

    • You will still need to add the BDR extension. But you will be able to use unmodified PostgreSQL 9.6, not the BDR PostgreSQL fork.

      So “sort-of”. It’s now more like installing pglogical or PostGIS, something you can add to an existing PostgreSQL install.

  • andreak

    So, to the “I want this feature” question; Will BDR ever support EXCLUTION-constraints?
    If not, do you have any suggestions on how to design around it?

    Thanks.

    • The only way BDR can ever support exclusion constraints is by doing synchronous changes. Once we can decode 2-phase transactions, we’ll be able to PREPARE TRANSACTION and replicate the xact to all nodes, where we PREPARE TRANSACTION there too. Only once all nodes confirm success will we COMMIT PREPARED on all nodes.

      Needless to say, this will be very slow, and only work when all nodes are up. It’s the same approach we want to use to clean up DDL handling.

      Fundamentally, exclusion constraints just don’t make sense in an asynchronous multi-master replication scheme.

        • BDR doesn’t fire triggers on replicated rows, it runs as session_replication_role = replica. So you can try, but it won’t work.

          State between nodes is asynchronously replicated, so it’s eventually consistent. That means that anything relying on a single-point-in-time globally consistent view of the system state will not work.

          If you need global point-in-time consistency you need another product that does global transaction management, global lock management, has global snapshots, etc. The trade-off is it’ll have poor performance over high latency networks and won’t tolerate network partitions.

    • Customer priorities are elsewhere, so it’s not likely to happen soon unless a support/consulting customer needs it and funds it. Right now we’re more focused on HA improvements.

      Adding Windows support probably isn’t that hard. Just have to make it work with EXEC_BACKEND and add a Windows-friendly CreateProcessEx(...) variant of the bdr_dump invocation code in bdr_init_copy.c. We go to some effort not to rely on direct access to memory inherited by fork()ing from the postmaster in the BDR management routines so it shouldn’t be a ton of work.

      If you or someone else who needs it submits a good quality patch I’d be happy to review and integrate it.

    • That’s up to Amazon. Amazon curates the extensions they allow to run on RDS, you cannot just install any extension you like on their sealed-system platform.

      To run BDR you must both be able to install C extensions and make connections as superuser. RDS does not allow anyone except Amazon to do either, so it’s up to them.

  • Uttam

    You mentioned different approach to handle global sequences. Can you please elaborate or give link to details of different approach we need to take?

    • I’m working on a new model for inclusion in 9.6-compatible BDR, but it won’t be in the alpha release, which will not have global sequences at all. When complete it’ll be covered in the documentation. I haven’t written it up at this point and don’t have time to explain in detail right now.

      If you decide to try the alpha of 9.6bdr or want to avoid use of seqam-based global sequences on 9.4bdr you can use simple step/offset sequences.

    • There will not be BDR support for 9.5, as I’ve been saying for some time.

      The patches required to make it work on 9.5 didn’t get in in time, they’re only in 9.6. So BDR for 9.5 would require another custom-patched PostgreSQL, which is more code maintenance burden. The only reason to bother supporting 9.5 would’ve been if it let us deliver BDR on unpatched PostgreSQL earlier. So it’s only targeting 9.6.

      We’re continuing to support customers using BDR on 9.4 and will continue to enhance it for 9.4bdr and 9.6, with a growing focus on 9.6 as support matures.

    • You don’t, yet. This post isn’t “hey, BDR for PostgreSQL 9.6 is ready and there are packages out”. It’s a heads-up that it’s well under way and will be entering early preview soon.

      When released for preview it will probably only be available as source code for you to compile yourself. Partly because at that stage we won’t want anyone getting the idea it’s ready for production use on 9.6 yet. The updated DDL replication and sequence handling will probably still be too raw.

      Keep an eye out, when there are RPMs it’ll be announced. But it’ll be quite a while yet, well after we do a preview release and likely an alpha or two. We’re unlikely to do RPMs before beta.

      If you’re really really keen you can try the current codebase from the relevant branch of the BDR project github. Be aware it’s subject to rebasing and regular incompatible updates.

      • Sinc

        Can you give us an idea when “quite a while” might be? Is that likely to be 2016, or March or late 2017, or when? My company is looking for this feature and we’re wondering when a relatively safe version based on 9.6 might be ready.

        (And of course I understand that you can’t commit to a date, but I’d love a best guess at this point.)

        Thanks

    • Yep. Be aware that the branch is subject to rebasing and forced pushes. The docs aren’t updated yet, and some tests are still known to fail on 9.6. The extension control files are updated in place, so pulling new versions of the branch may render existing installs incompatible. There’s a known bug with GRANTs not replicating. Don’t let it anywhere near production systems yet.

      I’d be interested in your comments on the DDL replication model used for 9.6bdr. We’re currently evaluating whether it’s good enough or whether we need to update DDL deparse and return to an event trigger based approach.

      Once the new global sequence code is completed I’d value input on it too; see bdr_seq2.c . Right now it works but doesn’t allocate node sequence IDs yet, I’m working on the required voting for that.

  • Hi Craig

    Thanks for this.

    https://github.com/2ndQuadrant/bdr/tree/bdr-plugin/next (upd. 8 days ago) has a README.bdr mentioning PG 9.4.

    https://github.com/2ndQuadrant/bdr/tree/bdr-plugin/dev-bdr96 (6 hours) also mentions 9.4.

    I’ll ignore that README and take the dev-bdr96 as you suggest.

    Likewise your page (https://github.com/2ndQuadrant) says

    postgres
    forked from postgres/postgres
    Patches and working trees for commitfests and public hackers posts.
    Updated a day ago

    https://github.com/2ndQuadrant/postgres/tree/master has a last update of Apr 17. The other most active branches are 6+ days old.

    Should I take the ‘official’ PG from https://github.com/postgres/postgres (last updated 19 hours ago) ?

    It seems Apr 17 is too far back; and I probably should not take your 6-day-old branch (dev/backport-95-tap-to-95 Updated 6 days ago by ringerc).

    I’ll try both in order for now.

    Of particular interest is whether the ALTER TABLE limitation described in http://stackoverflow.com/questions/32748630/django-1-8-migration-with-postgres-bdr-9-4-1

    Thanks

    Freddie

    • Short-version answer for others here: build against stock community postgres 9.6. The 2ndQuadrant ‘postgres’ repo is unrelated and, per the description, used to track and collaborate on patches destined for core.

      The docs are not updated at all in 9.6bdr yet, that includes the README.

      The limitation on full table rewrites in ALTER is not lifted. It’s technically possible, but requires extra work that isn’t currently roadmapped. If it’s important to you please get in touch with the consulting team – our priorities are driven by customer needs.

  • Hello

    I’m encountering some issues building bdr from source (branch bdr-plugin/dev-bdr96) but don’t want to spam here; could you tell me where to mail/post/etc if relevant and possible ?

    F

    • Yes, actually it’s now available for early access to 2ndQuadrant customers, and customers are testing it for production deployments.

      Get in touch with info@2ndquadrant.com if you’d like to learn more about the customer early access program.

      Public GA will be in the 2nd half of 2017.

Leave a Reply

Your email address will not be published. Required fields are marked *