pg.ddx.io pgsql-hackers@postgresql.org mailing list archive help / color / mirror / Atom feed From: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
To: pgsql-hackers@postgresql.org
Subject: Re: logical decoding of two-phase transactions
Date: Tue, 31 Jan 2017 12:42:31 +0300
Message-ID: <e4485c64-b4aa-4879-fe7a-ea58052c0877@postgrespro.ru> (raw )
In-Reply-To: <CAB7nPqQogmPYRkb=wwA4veeAWZXwDXQA64vw7fO_mHuDhAOHoA@mail.gmail.com >
References: <02DA5F5E-CECE-4D9C-8B4B-418077E2C010@postgrespro.ru >
<CANP8+jJGRpczm8L=LQCzuiEG3qHbY1cQB+T4A-cct7xgFmjj9g@mail.gmail.com >
<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 >
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 31.01.2017 09:29, Michael Paquier wrote:
> On Fri, Jan 27, 2017 at 8:52 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
>> Now, if it's simpler to just xlog the gid at COMMIT PREPARED time when
>> wal_level >= logical I don't think that's the end of the world. But
>> since we already have almost everything we need in memory, why not
>> just stash the gid on ReorderBufferTXN?
> I have been through this thread... And to be honest, I have a hard
> time understanding for which purpose the information of a 2PC
> transaction is useful in the case of logical decoding. The prepare and
> commit prepared have been received by a node which is at the root of
> the cluster tree, a node of the cluster at an upper level, or a
> client, being in charge of issuing all the prepare queries, and then
> issue the commit prepared to finish the transaction across a cluster.
> In short, even if you do logical decoding from the root node, or the
> one at a higher level, you would care just about the fact that it has
> been committed.
Sorry, may be I do not completely understand your arguments.
Actually our multimaster is completely based now on logical replication
and 2PC (more precisely we are using 3PC now:)
State of transaction (prepared, precommitted, committed) should be
persisted in WAL to make it possible to perform recovery.
Recovery can involve transactions in any state. So there three records
in the WAL: PREPARE, PRECOMMIT, COMMIT_PREPARED and
recovery can involve either all of them, either
PRECOMMIT+COMMIT_PREPARED either just COMMIT_PREPARED.
--
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
view thread (644+ messages) latest in thread
Message-ID: <e4485c64-b4aa-4879-fe7a-ea58052c0877@postgrespro.ru>
Permalink: ../e4485c64-b4aa-4879-fe7a-ea58052c0877@postgrespro.ru/
Also on: postgresql.org/message-id/e4485c64-b4aa-4879-fe7a-ea58052c0877@postgrespro.ru
copy link · copy postgr.es
reply 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: k.knizhnik@postgrespro.ru
Subject: Re: logical decoding of two-phase transactions
In-Reply-To: <e4485c64-b4aa-4879-fe7a-ea58052c0877@postgrespro.ru>
* 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