Re: - Mailing list pgsql-admin
From | MichaelDBA@sqlexec.com |
---|---|
Subject | Re: |
Date | |
Msg-id | 8946533D-5917-4266-B435-21CBF74852FA@sqlexec.com Whole thread Raw |
In response to | Re: Re: Re: (Simon Riggs <simon.riggs@enterprisedb.com>) |
List | pgsql-admin |
Hi Simon, Thanks for taking your time to elaborate. Sent from my iPhone > On Nov 24, 2021, at 5:00 PM, Simon Riggs <simon.riggs@enterprisedb.com> wrote: > > On Wed, 24 Nov 2021 at 18:18, MichaelDBA <MichaelDBA@sqlexec.com> wrote: >> >> Thanks, Simon, for your continued feedback. >> >> Simon Riggs wrote on 11/24/2021 12:49 PM: >> >> Anyone interested to know more can start here: >> https://www.enterprisedb.com/products/bidirectional-replication-bdr-postgresql-database > > You clearly have an interest in BDR, and some knowledge of BDR1, so I > thank you for that. > > The limitations of BDR1, written in 2014, are not limitations of the > architecture in general, merely things it didn't do. That has led to > some misunderstandings about what is possible and regrettably some > incorrect points have been made that I've attempted to rebut. Some of > those points relate to how Postgres-XL worked, but are not relevant to > BDR. > > 7 years later, BDR3 has a significant number of features not present > in BDR1. That may not be as well known, since as you say, BDR3 is not > fully open source. I regret that I was not able to fund further > development of BDR without charging users. Having said that, probably > more than 50% of BDR features are actually open source and part of > PostgreSQL - the contribution of new features has continued with each > new release. > > Specific to this conversation, BDR3 supports multiple transaction > modes - with various kinds of consistency. I would point out that > those modes are slower - which is why multiple options are present. > Some modes allow conflicts, some do not. This has nothing to do with > "Loosely-coupled", which does not present a limitation. > > Should a conflict occur, a conflict doesn't *inevitably* cause a > rollback/suspension requiring manual intervention. That doesn't seem > to be a fair characterisation of the current behavior, which again > differs significantly from BDR1. Just like any form of replication, > various actions can cause breakage or difficulties. > > Thank you for pointing out deficiencies in the docs. I wrote a large > part of it myself over many years and it seems we haven't yet captured > all of the possible options there. > > I'll work on improving the information available to help those > interested in BDR and/or related tech. > > -- > Simon Riggs http://www.EnterpriseDB.com/
pgsql-admin by date: