MIME-Version: 1.0
References: 
 <CAAXajwDOvTwLQ=rO5hOKsR_VTikST1rN-moO46YhYEgsO00dqg@mail.gmail.com>
 <2DCDBFFC-4B03-4EBC-88A3-06AD29933F17@yandex-team.ru>
 <CAAXajwD5pT+BtQqLTn=6DDs8NAWgqm4S6esSn0Zr3Ev1kVbYPg@mail.gmail.com>
In-Reply-To: 
 <CAAXajwD5pT+BtQqLTn=6DDs8NAWgqm4S6esSn0Zr3Ev1kVbYPg@mail.gmail.com>
Reply-To: zaartur@gmail.com
From: Artur Zakirov <zaartur@gmail.com>
Date: Mon, 30 Mar 2026 12:44:23 +0200
Message-ID: 
 <CAKNkYnzAOcMr4j-ku=+jr29EssA=Ct3NX99rr=+HcRVeQD_Yyw@mail.gmail.com>
Subject: Re: [PATCH] Add prepared_orphaned_transaction_timeout GUC
To: Nikhil Chawla <chawlanikhil24@gmail.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAKNkYnzAOcMr4j-ku%3D%2Bjr29EssA%3DCt3NX99rr%3D%2BHcRVeQD_Yyw%40mail.gmail.com>
Precedence: bulk

>> Silent rollback in any scenario I can imagine is a disaster.
> ...
> The same analogy is being applied with orphaned prepared transactions, wh=
ich may/may not complete ever , but going to hinder autovacuum, increasing =
bloat. When user sets the value, user will be aware that the prepared trans=
actions 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.