Re: [HACKERS] pg_prepared_xact_status

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: [HACKERS] pg_prepared_xact_status
Дата
Msg-id CAMsr+YE7c=VW-4VBFhqCH38yYkN99+GrCb5YQQvr8_8j9pyHgg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] pg_prepared_xact_status  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Ответы Re: [HACKERS] pg_prepared_xact_status  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Список pgsql-hackers
Дерево обсуждения
On 29 September 2017 at 15:57, Konstantin Knizhnik <k.knizhnik@postgrespro.ru> wrote:
 
So you are saying that Postgresql 2PC mechanism is not complete and user needs to maintain some extra information to make it work?

No, it provides what's needed for an implementation of what in XA terms is a local resource manager (LRM). What it does not provide is infrastructure to make postgres its self into a global transaction manager (GTM) for co-ordinating multiple LRMs.

It sounds like you're trying to build a GTM using PostgreSQL's existing LRM book-keeping as your authorative data store, right?
 
The problems with 2PC arrive when coordinator node is not available but is expected to be recovered in future.
In this case we may have not enough information to make a decision whether to abort or commit prepared transaction.
But it is a different story. We need to use 3PC or some other protocol to prevent such situation.

In that case the node sits and waits patiently for the GTM (or in more complex architectures, *a* valid voting quorum of GTMs) to be reachable again. Likely using a protocol like Raft, Paxos, 3PC etc to co-ordinate.

It can't do anything else, since if it unilaterally commits or rolls back it might later find out that the nodes on the other side of the network partition or whatever made the opposite decision and, boom!

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

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

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: [HACKERS] Walsender timeouts and large transactions
Следующее
От: tushar
Дата:
Сообщение: Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with alot of columns