Message-ID: <589241FB.8060509@postgrespro.ru>
Date: Wed, 01 Feb 2017 23:15:55 +0300
From: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>
CC: Michael Paquier <michael.paquier@gmail.com>,
 Craig Ringer <craig@2ndquadrant.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
 Stas Kelvich <s.kelvich@postgrespro.ru>,
 Simon Riggs <simon@2ndquadrant.com>
Subject: Re: logical decoding of two-phase transactions
References: <02DA5F5E-CECE-4D9C-8B4B-418077E2C010@postgrespro.ru>
 <CANP8+jJ+=hwLcDSNAqBmZwHh0Pb46SERQsBC1i4VCpkgkL9Jjg@mail.gmail.com>
 <D11D3072-6A72-439C-8B62-1D2628134A60@postgrespro.ru>
 <CANP8+j+xxYB5GoFebq1NGm17TEAaZ=JvM-Ok-Hp+n6De3pseeA@mail.gmail.com>
 <DED204B8-0877-4BAB-B2FE-0F450BD56186@postgrespro.ru>
 <CAMsr+YH0aRgnk8XwyYypV1E10DNXwgGpWTLq_P2MGjACpiwMpA@mail.gmail.com>
 <89073436-925E-4299-A9AF-88D04E55C231@postgrespro.ru>
 <CAMsr+YGX6Q-VNXEhu3sriCf0wCS6hjQ0Lhj4rJ8VueVuuka+fg@mail.gmail.com>
 <3477E635-F590-4432-BD20-C59142B65CD3@postgrespro.ru>
 <CAMsr+YHos95GFyfd2Gk61-66wpxFTgXJh=sBV3Rtfhe3xzG1HQ@mail.gmail.com>
 <CAB7nPqQogmPYRkb=wwA4veeAWZXwDXQA64vw7fO_mHuDhAOHoA@mail.gmail.com>
 <CAMsr+YHQzGxnR-peT4SbX2-xiG2uApJMTgZ4a3TiRBM6COyfqg@mail.gmail.com>
 <CAB7nPqSQPANEwaLm1GU4MYjENrRgetiRCxhWoP-ATQbutWm+Yw@mail.gmail.com>
 <CA+TgmoY7sqHfc=tgTPO6695gOF4bykWRO3fnk7bQr+ij5eycew@mail.gmail.com>
 <19628.1485977554@sss.pgh.pa.us>
In-Reply-To: <19628.1485977554@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 02/01/2017 10:32 PM, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Also, including the GID in the WAL for each COMMIT/ABORT PREPARED
>> doesn't seem inordinately expensive to me.
> I'm confused ... isn't it there already?  If not, how do we handle
> reconstructing 2PC state from WAL at all?
>
> 			regards, tom lane
>
>
Right now logical decoding ignores prepare and take in account only "commit prepared":

            /*
             * Currently decoding ignores PREPARE TRANSACTION and will just
             * decode the transaction when the COMMIT PREPARED is sent or
             * throw away the transaction's contents when a ROLLBACK PREPARED
             * is received. In the future we could add code to expose prepared
             * transactions in the changestream allowing for a kind of
             * distributed 2PC.
             */

For some scenarios it works well, but if we really need prepared state at replica (as in case of multimaster), then it is not enough.

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers