Re: Do we need to handle orphaned prepared transactions in the server?
От | Ants Aasma |
---|---|
Тема | Re: Do we need to handle orphaned prepared transactions in the server? |
Дата | |
Msg-id | CANwKhkPEm5mjGOZNt_h4hmkBsTP0zedgQMFRRsKn4Ts_Y7Zh9w@mail.gmail.com обсуждение исходный текст |
Ответ на | Do we need to handle orphaned prepared transactions in the server? (Hamid Akhtar <hamid.akhtar@gmail.com>) |
Ответы |
Re: Do we need to handle orphaned prepared transactions in the server?
|
Список | pgsql-hackers |
On Wed, 22 Jan 2020 at 09:02, Hamid Akhtar <hamid.akhtar@gmail.com> wrote: > > At this stage, I'm not sure of the scale of changes this will require, however, I wanted to get an understanding and consensuson whether (a) this is something we should work on, and (b) whether an approach to implementing a timeout makessense. > > Please feel free to share your thoughts here. The intended use case of two phase transactions is ensuring atomic durability of transactions across multiple database systems. This necessarily means that there needs to be a failure tolerant agent that ensures there is consensus about the status of the transaction and then executes that consensus across all systems. In other words, there needs to be a transaction manager for prepared statements to actually fulfil their purpose. Therefore I think that unilaterally timing out prepared statements is just shifting the consequences of a broken client from availability to durability. But if durability was never a concern, why is the client even using prepared statements? Citing the documentation: > PREPARE TRANSACTION is not intended for use in applications or interactive sessions. Its purpose is to allow an externaltransaction manager to perform atomic global transactions across multiple databases or other transactional resources.Unless you're writing a transaction manager, you probably shouldn't be using PREPARE TRANSACTION. Regards, Ants Aasma
В списке pgsql-hackers по дате отправления: