Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cP7Nw-0003Fl-Mq for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Jan 2017 12:43:12 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cP7Nv-0000g9-Tr for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Jan 2017 12:43:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cP7Nv-0000g1-E5 for pgsql-hackers@postgresql.org; Thu, 05 Jan 2017 12:43:11 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by magus.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cP7Nr-0006of-NX for pgsql-hackers@postgresql.org; Thu, 05 Jan 2017 12:43:10 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 5072B21C22EE; Thu, 5 Jan 2017 15:43:05 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1483620185; bh=Qy5/3oFmgc96kdYbNntkk2Br0azHycSwmtFOD/QLAIk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=pliLmjusziAIO1GGbUyZ/cRN2nJ4ZDIJ8f0c1YZNsq5y+9G/CgsFugtgKCNE96slT YezHqdZsNJImwpx+NRhE6oxIx1qhrsF6eR4n3cGSC0AOPDledtYimmODpC5J9yOWWp zSRSfeScSL6n8xwhj8ibDG6kAxPNU0dEfEN9/8zs= Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: logical decoding of two-phase transactions From: Stas Kelvich In-Reply-To: Date: Thu, 5 Jan 2017 15:43:04 +0300 Cc: PostgreSQL mailing lists , Craig Ringer Content-Transfer-Encoding: quoted-printable Message-Id: References: <02DA5F5E-CECE-4D9C-8B4B-418077E2C010@postgrespro.ru> To: Simon Riggs X-Mailer: Apple Mail (2.3259) X-Pg-Spam-Score: -5.2 (-----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org > On 5 Jan 2017, at 13:49, Simon Riggs wrote: >=20 > Surely in this case the master server is acting as the Transaction > Manager, and it knows the mapping, so we are good? >=20 > I guess if you are using >2 nodes then you need to use full 2PC on each n= ode. >=20 > Please explain precisely how you expect to use this, to check that GID > is required. >=20 For example if we are using logical replication just for failover/HA and al= lowing user to be transaction manager itself. Then suppose that user prepared tx on ser= ver A and server A crashed. After that client may want to reconnect to server B and commit/abo= rt that tx. But user only have GID that was used during prepare. > But even then, if you adopt the naming convention that all in-progress > xacts will be called RepOriginId-EPOCH-XID, so they have a fully > unique GID on all of the child nodes then we don't need to add the > GID. Yes, that=E2=80=99s also possible but seems to be less flexible restricting= us to some specific GID format. Anyway, I can measure WAL space overhead introduced by the GID=E2=80=99s in= side commit records to know exactly what will be the cost of such approach. --=20 Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company --=20 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers