From: Andy Fan <zhihuifan1213@163.com>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: raise ERROR between EndPrepare and PostPrepare_Locks causes
 ROLLBACK 2pc PAINC
User-Agent: mu4e 1.14.0-pre2; emacs 30.2
Date: Tue, 24 Mar 2026 18:04:43 +0800
Message-ID: <87341p7dc4.fsf@163.com>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://www.postgresql.org/message-id/87341p7dc4.fsf%40163.com>
Precedence: bulk

Hi,

With the following hack in PrepareTransaction:

@@ -2697,6 +2697,8 @@ PrepareTransaction(void)
 	 */
 	EndPrepare(gxact);
 
+	elog(ERROR, "some error");
+
 	/*
 	 * Now we clean up backend-internal state and release internal resources.
 	 */

Then we can do the following test:
CREATE TABLE t(a int);
begin;
insert into t values(1);
prepare transaction 'foo';
ERROR: some error.  //  before the lock transfer
rollback prepared 'foo';
PANIC:  failed to re-find shared lock object // because lock is released
when ERROR.

One of the methods in my mind is to delay the END_CRIT_SECTION until
PostPrepare_Locks is finished, then the above case would become:

(1)  ERROR
(2)  Since CRIT_SECTION, error become to PAINC.
(3)  client get PAINC and know the prepare failure.
(4). server does crash-recovery and the [2pc is recovered] (even client
has get error).
(5). We (as postgresql developer) should expected 2pc coordinator to run
"rollback prepared foo" anyway even the prepared failure and handle the
case where 'foo' doesn't exist.

I don't think it is a good solution because the mismatch between
(3) and (4).  and the error handle in step (5).

This is not a real case to me, I just run into this with a
fault-injection testing framework. So after all is this something
which deserves a fix?  

-- 
Best Regards
Andy Fan