Re: [HACKERS] logical decoding of two-phase transactions

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] logical decoding of two-phase transactions
Дата
Msg-id CAB7nPqQogmPYRkb=wwA4veeAWZXwDXQA64vw7fO_mHuDhAOHoA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] logical decoding of two-phase transactions  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: [HACKERS] logical decoding of two-phase transactions  (Michael Paquier <michael.paquier@gmail.com>)
Re: [HACKERS] logical decoding of two-phase transactions  (Craig Ringer <craig@2ndquadrant.com>)
Re: [HACKERS] logical decoding of two-phase transactions  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Список pgsql-hackers
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.
-- 
Michael



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] pgbench - allow to store select results intovariables
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] logical decoding of two-phase transactions