Re: [HACKERS] logical decoding of two-phase transactions - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] logical decoding of two-phase transactions
Date
Msg-id CAB7nPqSrk255+zBRL9E97YSMJgBjW_LM60jckPKrnbJot9PELw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] logical decoding of two-phase transactions  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Tue, Jan 31, 2017 at 3:29 PM, Michael Paquier
<michael.paquier@gmail.com> 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.

By the way, I have moved this patch to next CF, you guys seem to make
the discussion move on.
-- 
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] patch: function xmltable