public inbox for [email protected]  

help / color / mirror / Atom feed

From: Artur Zakirov <[email protected]>
To: Nikhil Chawla <[email protected]>
Cc: Andrey Borodin <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] Add prepared_orphaned_transaction_timeout GUC
Date: Mon, 30 Mar 2026 12:44:23 +0200
Message-ID: <CAKNkYnzAOcMr4j-ku=+jr29EssA=Ct3NX99rr=+HcRVeQD_Yyw@mail.gmail.com> (raw)
In-Reply-To: <CAAXajwD5pT+BtQqLTn=6DDs8NAWgqm4S6esSn0Zr3Ev1kVbYPg@mail.gmail.com>
References: <CAAXajwDOvTwLQ=rO5hOKsR_VTikST1rN-moO46YhYEgsO00dqg@mail.gmail.com>
	<[email protected]>
	<CAAXajwD5pT+BtQqLTn=6DDs8NAWgqm4S6esSn0Zr3Ev1kVbYPg@mail.gmail.com>

>> Silent rollback in any scenario I can imagine is a disaster.
> ...
> The same analogy is being applied with orphaned prepared transactions, which may/may not complete ever , but going to hinder autovacuum, increasing bloat. When user sets the value, user will be aware that the prepared transactions can disappear automatically.

I agree with Andrey. And I think we cannot use the same analogy of
"long running transactions" to prepared transactions. Prepared
transactions are part of 2PC protocol. And this GUC would break 2PC
protocol, which is after all distributed participants successfully
executed PREPARE you can successfully execute COMMIT, if a database is
healthy.

Another point is that rollback is not always a proper action on a
dangling prepared transaction. If you move data from Instance1 to
Instance2 and a prepared transaction on Instance1 was committed, but
you have a dangling prepared transaction on Instance2 for some reason,
then you want to COMMIT it on Instance2, not to roll back. And vice
versa, if the prepared transaction on Instance1 was rolled back, then
you want to roll it back on Instance2. What to do with the prepared
transaction should be decided by a transaction manager.

view thread (4+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [PATCH] Add prepared_orphaned_transaction_timeout GUC
  In-Reply-To: <CAKNkYnzAOcMr4j-ku=+jr29EssA=Ct3NX99rr=+HcRVeQD_Yyw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox