Re: XA support (distributed transactions)
От | Florian G. Pflug |
---|---|
Тема | Re: XA support (distributed transactions) |
Дата | |
Msg-id | 4561EA20.4080208@phlo.org обсуждение исходный текст |
Ответ на | XA support (distributed transactions) (Danny Milosavljevic <danny.milosavljevic@fabalabs.org>) |
Ответы |
Re: XA support (distributed transactions)
Re: XA support (distributed transactions) Re: XA support (distributed transactions) |
Список | pgsql-hackers |
Danny Milosavljevic wrote: > Hi, > > We (Fabalabs) are looking into adding XA support (distributed > transactions) to Postgresql. Postgres already supports 2 phase commits, which is can basis on which XA can be implemented I think. The "only" missing part is an transaction manager, but that wouldn't have to be integrated into postgres. As far as I understand things, the only thing you really need the transaction manager for is for automatic recovery if one member of a distributed transaction fails while the transaction is still in progress. In that case the transaction manager needs to either rollback the transaction, if it wasn't already prepared on all nodes, or commit it. The only difficulty I see in this "transaction manager" is that it will needto (persistenly) keep track of transactions, because due to the design of 2-phase-commit, you cannot deduce the faith of a transaction by just looking at the nodes. Image you find a transaction that is prepared in 3 out of 5 participating nodes. It might be that it was originally prepared on all 5 nodes, and already comitted on two of them, or it might have been comitted on only 3 nodes before the transaction manager itself crashed. In the first case you should commit the transaction on those 3 nodes, while you should roll it back in the second case. I believe there are open-source implementations of such transaction managers, but I don't have any links at hand. greetings, Florian Pflug
В списке pgsql-hackers по дате отправления: