From: Petr Jelinek <petr.jelinek@2ndquadrant.com>
To: Craig Ringer <craig@2ndquadrant.com>
To: Stas Kelvich <s.kelvich@postgrespro.ru>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: logical decoding of two-phase transactions
Date: Thu, 2 Mar 2017 17:34:18 +0100
Message-ID: <abf61103-fff7-c7c3-481f-e2729db0e069@2ndquadrant.com> (raw)
In-Reply-To: <CAMsr+YF9a+S6uKAUEFumsAP=Kpj_Ko7kfueTCm27MoNYOwFdmg@mail.gmail.com>
References: <02DA5F5E-CECE-4D9C-8B4B-418077E2C010@postgrespro.ru>
<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>
<1FE466EA-7058-484D-B0DB-42CD81FA59F0@postgrespro.ru>
<CAMsr+YHVNW-Lh-XnYnkfhGL2QT8kK9kM4zkZ4+Sv=fszhujj-g@mail.gmail.com>
<46ebc39d-82a0-e59f-2552-2ea8911a64e7@2ndquadrant.com>
<DFE91C41-1410-4D89-B7D6-819F5FDC1437@postgrespro.ru>
<CAMsr+YHbvCtVetrtJ1_LCKen98d3cG8zmHP_-nSm=aDj6yc0vQ@mail.gmail.com>
<25A09FA8-5B0E-447D-97FB-F37F3B0E34E9@postgrespro.ru>
<CAMsr+YF9a+S6uKAUEFumsAP=Kpj_Ko7kfueTCm27MoNYOwFdmg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 02/03/17 13:23, Craig Ringer wrote:
> On 2 March 2017 at 16:20, Stas Kelvich <s.kelvich@postgrespro.ru> wrote:
>>
>>> On 2 Mar 2017, at 11:00, Craig Ringer <craig@2ndquadrant.com> wrote:
>>>
>>> We already have it, because we just decoded the PREPARE TRANSACTION.
>>> I'm preparing a patch revision to demonstrate this.
>>
>> Yes, we already have it, but if server reboots between commit prepared (all
>> prepared state is gone) and decoding of this commit prepared then we loose
>> that mapping, isn’t it?
>
> I was about to explain how restart_lsn works again, and how that would
> mean we'd always re-decode the PREPARE TRANSACTION before any COMMIT
> PREPARED or ROLLBACK PREPARED on crash. But...
>
> Actually, the way you've implemented it, that won't be the case. You
> treat PREPARE TRANSACTION as a special-case of COMMIT, and the client
> will presumably send replay confirmation after it has applied the
> PREPARE TRANSACTION. In fact, it has to if we want 2PC to work with
> synchronous replication. This will allow restart_lsn to advance to
> after the PREPARE TRANSACTION record if there's no other older xact
> and we see a suitable xl_running_xacts record. So we wouldn't decode
> the PREPARE TRANSACTION again after restart.
>
Unless we just don't let restart_lsn to go forward if there is 2pc that
wasn't decoded yet (twopcs store the prepare lsn) but that's probably
too much of a kludge.
>
> It's also worth noting that with your current approach, 2PC xacts will
> produce two calls to the output plugin's commit() callback, once for
> the PREPARE TRANSACTION and another for the COMMIT PREPARED or
> ROLLBACK PREPARED, the latter two with a faked-up state. I'm not a
> huge fan of that. It's not entirely backward compatible since it
> violates the previously safe assumption that there's a 1:1
> relationship between begin and commit callbacks with no interleaving,
> for one thing, and I think it's also a bit misleading to send a
> PREPARE TRANSACTION to a callback that could previously only receive a
> true commit.
>
> I particularly dislike calling a commit callback for an abort. So I'd
> like to look further into the interface side of things. I'm inclined
> to suggest adding new callbacks for 2pc prepare, commit and rollback,
> and if the output plugin doesn't set them fall back to the existing
> behaviour. Plugins that aren't interested in 2PC (think ETL) should
> probably not have to deal with it, we might as well just send them
> only the actually committed xacts, when they commit.
>
I think this is a good approach to handle it.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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-hackers@postgresql.org
Cc: petr.jelinek@2ndquadrant.com, craig@2ndquadrant.com, s.kelvich@postgrespro.ru, michael.paquier@gmail.com, simon@2ndquadrant.com, robertmhaas@gmail.com, tgl@sss.pgh.pa.us
Subject: Re: logical decoding of two-phase transactions
In-Reply-To: <abf61103-fff7-c7c3-481f-e2729db0e069@2ndquadrant.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