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
|
Список | 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 по дате отправления: