Re: Do we need to handle orphaned prepared transactions in the server?

From: Ants Aasma <ants(at)cybertec(dot)at>
To: Hamid Akhtar <hamid(dot)akhtar(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Do we need to handle orphaned prepared transactions in the server?
Date: 2020-01-22 08:45:21
Message-ID: CANwKhkPEm5mjGOZNt_h4hmkBsTP0zedgQMFRRsKn4Ts_Y7Zh9w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 22 Jan 2020 at 09:02, Hamid Akhtar <hamid(dot)akhtar(at)gmail(dot)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 consensus on whether (a) this is something we should work on, and (b) whether an approach to implementing a timeout makes sense.
>
> 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 external transaction 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message MBeena Emerson 2020-01-22 09:53:15 Re: Error message inconsistency
Previous Message Masahiko Sawada 2020-01-22 08:37:06 Re: error context for vacuum to include block number