From: MichaelDBA@sqlexec.com <michaeldba@sqlexec.com>
To: Simon Riggs <simon.riggs@enterprisedb.com>
Cc: Holger Jakobs <holger@jakobs.com>
Cc: pgsql-admin@lists.postgresql.org, Firthouse banu <penguinsfairy@gmail.com>
Cc: pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re:
Date: Wed, 24 Nov 2021 17:26:11 -0500
Message-ID: <8946533D-5917-4266-B435-21CBF74852FA@sqlexec.com> (raw)
In-Reply-To: <CANbhV-HsLrE+hpgFJXHG08k5h5HM+7g+4wMtkk_wR9GnbzMNKg@mail.gmail.com>
References: <CANbhV-HsLrE+hpgFJXHG08k5h5HM+7g+4wMtkk_wR9GnbzMNKg@mail.gmail.com>
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/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: michaeldba@sqlexec.com, simon.riggs@enterprisedb.com, holger@jakobs.com, penguinsfairy@gmail.com
Subject: Re:
In-Reply-To: <8946533D-5917-4266-B435-21CBF74852FA@sqlexec.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox