Re: Transactions involving multiple postgres foreign servers

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Transactions involving multiple postgres foreign servers
Дата
Msg-id 54B1D3C5.9080404@BlueTreble.com
обсуждение исходный текст
Ответ на Re: Transactions involving multiple postgres foreign servers  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Transactions involving multiple postgres foreign servers  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On 1/10/15, 7:11 AM, Michael Paquier wrote:
>> If we had an independent transaction coordinator then I agree with you
>> >Kevin. I think Robert is proposing that if we are controlling one of the
>> >nodes that's participating as well as coordinating the overall transaction
>> >that we can take some shortcuts. AIUI a PREPARE means you are completely
>> >ready to commit. In essence you're just waiting to write and fsync the
>> >commit message. That is in fact the state that a coordinating PG node would
>> >be in by the time everyone else has done their prepare. So from that
>> >standpoint we're OK.
>> >
>> >Now, as soon as ANY of the nodes commit, our coordinating node MUST be able
>> >to commit as well! That would require it to have a real prepared transaction
>> >of it's own created. However, as long as there is zero chance of any other
>> >prepared transactions committing before our local transaction, that step
>> >isn't actually needed. Our local transaction will either commit or abort,
>> >and that will determine what needs to happen on all other nodes.
> It is a property of 2PC to ensure that a prepared transaction will
> commit. Now, once it is confirmed on the coordinator that all the
> remote nodes have successfully PREPAREd, the coordinator issues COMMIT
> PREPARED to each node. What do you do if some nodes report ABORT
> PREPARED while other nodes report COMMIT PREPARED? Do you abort the
> transaction on coordinator, commit it or FATAL? This lets the cluster
> in an inconsistent state, meaning that some consistent cluster-wide
> recovery point is needed as well (Postgres-XC and XL have introduced
> the concept of barriers for such problems, stuff created first by
> Pavan Deolassee).

My understanding is that once you get a successful PREPARE that should mean that it's basically impossible for the
transactionto fail to commit. If that's not the case, I fail to see how you can get any decent level of sanity out of
this...
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Using 128-bit integers for sum, avg and statistics aggregates
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)