On 31 Jan. 2017 22:43, "Konstantin Knizhnik" <k.knizh...@postgrespro.ru> wrote:
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. > 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. That's your modified Pg though. This 2pc logical decoding patch proposal is for core and I think it just confused things to introduce discussion of unrelated changes made by your product to the codebase. -- 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