Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mpwr8-0006iw-48 for pgsql-admin@arkaria.postgresql.org; Wed, 24 Nov 2021 18:18:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mpwr7-0000wD-2d for pgsql-admin@arkaria.postgresql.org; Wed, 24 Nov 2021 18:18:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mpwr6-0000w4-GN; Wed, 24 Nov 2021 18:18:52 +0000 Received: from mout.perfora.net ([74.208.4.196]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mpwr3-0000c6-A0; Wed, 24 Nov 2021 18:18:51 +0000 Received: from [192.168.1.167] ([98.169.214.209]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1M424C-1mpwqx3XIu-0003pt; Wed, 24 Nov 2021 19:18:43 +0100 Subject: Re: Re: Re: To: Simon Riggs Cc: Holger Jakobs , pgsql-admin@lists.postgresql.org, Firthouse banu , pgsql-admin References: <6cb32d43-75d1-b896-5267-48d75c536808@sqlexec.com> <0ED6B91F-C228-404F-A4F2-B9532E205B2D@jakobs.com> <7713c1fd-c674-eb79-02ea-0daf749ac098@sqlexec.com> From: MichaelDBA Message-ID: <77723597-904d-bdae-730a-752a6e4af7e0@sqlexec.com> Date: Wed, 24 Nov 2021 13:18:40 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.52 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------20369FD23FA66732DC1A0B80" Content-Language: en-US X-Provags-ID: V03:K1:wP9mB11Mp7Iq/lJFgFVjjcuu/ZXWZtrNOhTOKhUL4EyocKJv4he zxQgbXMxrILIWbc1uxlpQHunj/pAadsMjViEgaVSaIK0bUpdQhJ0pUuvJIHPXzqQwvh6/id 7tYbTH/ieVNb4sglysxH2+3kkHE/mN9NNLesGrWDg9PJfyXu23phUJSCpJ3qiipiaPYwMV8 hk59gmWC9r421mJ/hHewg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:VBldQA9sCGg=:32CIaHI+4gsD8nJwAhlH6y vyAlvY0QO+ESg9qiIj4bf3ZZck2suc0CpCjnW1ErjT3o3FN0VpGLpHkNxUamClaiUMOhozv6p t9EGsZ0GwqiRIZspZ7yrQgZw5mLC788afTfhGOBSfG3QXky6bnTb5GLAPD9ydDpjoECPV3k6e J4qxVoNw86wNLnKUFkXycmau+UYaGEkSayj1lPligGO1PBsnZZZ1OapSYEdmHHD8GjzmIvP8k pv2tcIf/bDNJRK8XYsXnQZd5UnMwP9MbuDAVyu4ClpaKQmYu4v1pv/gf2aQNOJQ2oKrsB3GZs hNVdlmrop3pdJa72kM1tnoCs3tqtjYkMOvvU9Po/D3dVq+5G/7Wz90oBaVU41cnscayn4/zn9 bjPkvOD34UWqpwiqUSXvh8JuXo29diPan4MpGsIQ/q0gLQl0sosobx7pM2/K+ZK4Sb0KGTfOf FMdC1237XrN/yR9QJkRwvjj3tqBk7HkELY3TDZy8JEb/XuJG4iO1e3OhN1922UKVzP6pLuvfz d24TwAs71aPT5PajR33LeuNJmJYiIc2RFVPmWOy1p5rPHc9arRmcxWAP3GVYU/T9RFZFmsoZc xGYY9ortiAZb2DB+q/O8PcKPC0X5vkBzehDEnzrE7aRVcb0VV1kteFPfbDWwPQbI1/BNbNAUw AdSCDOX3sSfpDthxSa+PVjDzfTX3VygE2Cf0kaIXlsDWRpBPAawQp36GkGhiRH8DprkwbnQhK IskB3gt/cIweA3kZ List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------20369FD23FA66732DC1A0B80 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks, Simon, for your continued feedback. Simon Riggs wrote on 11/24/2021 12:49 PM: > On Wed, 24 Nov 2021 at 17:38, MichaelDBA wrote: >> Oh really? BDR is acid-compliant? How can it be without a global lock manager to control access to resources and a consistent view of data and enforce isolation levels? > Many types of distributed system offer consistency. Very few use a > global lock manager, so this is not a requirement. Let me try to state it another way... Without a central place where you can see all the SQL coming against all of the read-write PG nodes at the same time, you cannot avoid conflicts.  PG is active/passive so it cannot resolve conflicts across multiple primary PG clusters.  Hence, BDR offers an "underneath the covers" approach to deal with conflicts when they do arise, but innevitably a conflict causes a previous commit to be rolled back or "suspended" for some kind of manual intervention later.  That is why BDR nowhere states that BDR is ACID-compliant. If it were ACID-compliant, there would be no external need to address SQL conflicts. >> Please explain the magic. > Anyone interested to know more can start here: > https://www.enterprisedb.com/products/bidirectional-replication-bdr-postgresql-database > I spent about 15 minutes starting at the URL stated above to drill down into some areas where this subject might be addressed and I couldn't find it.  Perhaps you could be more specific. I did find this in separate BDR documentation: "BDRis a loosely coupled shared-nothing multi-master design."  I guess you can say "loosely coupled" is a nice way to say not ACID-compliant. --------------20369FD23FA66732DC1A0B80 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks, Simon, for your continued feedback.

Simon Riggs wrote on 11/24/2021 12:49 PM:
On Wed, 24 Nov 2021 at 17:38, MichaelDBA <MichaelDBA@sqlexec.com> wrote:

Oh really?  BDR is acid-compliant? How can it be without a global lock manager to control access to resources and a consistent view of data and enforce isolation levels?

Many types of distributed system offer consistency. Very few use a
global lock manager, so this is not a requirement.
Let me try to state it another way... Without a central place where you can see all the SQL coming against all of the read-write PG nodes at the same time, you cannot avoid conflicts.  PG is active/passive so it cannot resolve conflicts across multiple primary PG clusters.  Hence, BDR offers an "underneath the covers" approach to deal with conflicts when they do arise, but innevitably a conflict causes a previous commit to be rolled back or "suspended" for some kind of manual intervention later.  That is why BDR nowhere states that BDR is ACID-compliant. If it were ACID-compliant, there would be no external need to address SQL conflicts.

Please explain the magic.

Anyone interested to know more can start here:
https://www.enterprisedb.com/products/bidirectional-replication-bdr-postgresql-database
I spent about 15 minutes starting at the URL stated above to drill down into some areas where this subject might be addressed and I couldn't find it.  Perhaps you could be more specific.
I did find this in separate BDR documentation: "BDR is a loosely coupled shared-nothing multi-master design."  I guess you can say "loosely coupled" is a nice way to say not ACID-compliant. --------------20369FD23FA66732DC1A0B80--