On 31.01.2017 09:29, Michael Paquier wrote:
On Fri, Jan 27, 2017 at 8:52 AM, Craig Ringer <cr...@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
