Re: Transactions involving multiple postgres foreign servers, take 2
От | Kyotaro Horiguchi |
---|---|
Тема | Re: Transactions involving multiple postgres foreign servers, take 2 |
Дата | |
Msg-id | 20210610.110420.1937270747453097649.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | RE: Transactions involving multiple postgres foreign servers, take 2 ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>) |
Ответы |
RE: Transactions involving multiple postgres foreign servers, take 2
("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
|
Список | pgsql-hackers |
At Tue, 8 Jun 2021 08:45:24 +0000, "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com> wrote in > From: Kyotaro Horiguchi <horikyota.ntt@gmail.com> > > I think the discussion is based the behavior that any process that is > > responsible for finishing the 2pc-commit continue retrying remote > > commits until all of the remote-commits succeed. > > Thank you for coming back. We're talking about the first attempt to prepare and commit in each transaction, not the retrycase. If we accept each elementary-commit (via FDW connection) to fail, the parent(?) there's no way the root 2pc-commit can succeed. How can we ignore the fdw-error in that case? > > > Throws: HeuristicMixedException > > > Thrown to indicate that a heuristic decision was made and that some > > relevant updates have been > > > committed while others have been rolled back. > > > I'm not sure about how JTA works in detail, but doesn't > > UserTransaction.commit() return HeuristicMixedExcpetion when some of > > relevant updates have been committed but other not? Isn't it the same > > state with the case where some of the remote servers failed on > > remote-commit while others are succeeded? > > No. Taking the description literally and considering the relevant XA specification, it's not about the remote commit failure. The remote server is not allowed to fail the commit once it has reported successful prepare, which is the contractof 2PC. HeuristicMixedException is about the manual resolution, typically by the DBA, using the DBMS-specific toolor the standard commit()/rollback() API. Mmm. The above seems as if saying that 2pc-comit does not interact with remotes. The interface contract does not cover everything that happens in the real world. If remote-commit fails, that is just an issue outside of the 2pc world. In reality remote-commit may fail for all reasons. https://www.ibm.com/docs/ja/db2-for-zos/11?topic=support-example-distributed-transaction-that-uses-jta-methods > } catch (javax.transaction.xa.XAException xae) > { // Distributed transaction failed, so roll it back. > // Report XAException on prepare/commit. This suggests that both XAResoruce.prepare() and commit() can throw a exception. > > (I guess that > > UserTransaction.commit() would throw RollbackException if > > remote-prepare has been failed for any of the remotes.) > > Correct. So UserTransaction.commit() does not throw the same exception if remote-commit fails. Isn't the HeuristicMixedExcpetion the exception thrown in that case? regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: