Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w5CHR-002zuf-1X for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Mar 2026 00:39:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w5CHP-009wpQ-39 for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Mar 2026 00:39:28 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w5CHP-009wpH-0D for pgsql-hackers@lists.postgresql.org; Wed, 25 Mar 2026 00:39:28 +0000 Received: from m16.mail.163.com ([117.135.210.4]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w5CHI-00000000sW9-0JXB for pgsql-hackers@lists.postgresql.org; Wed, 25 Mar 2026 00:39:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; bh=bwcq8Hs5QBYBVrrHXieZAu8ZhZFE6YM+ff9L48Gnfz4=; b=Zz6rgUrD0VNSsiBGgMmjw0SNZnezZKwReHvKAZe7uw44qIsgrcmD4qhzpwEsKl b4pTjScwl45TflP/mzKS20yq+Dcqus7n9WOP22PGo865Cu03hgJJb3j6OJ7qyfyj T8aOaG/jTwM95GPZKPzAVfjoJDLAQC8s29JY5awmDLT2c= Received: from andy-coding (unknown []) by gzsmtp1 (Coremail) with SMTP id PCgvCgAnQs+rLsNp5cy+Sg--.20204S3; Wed, 25 Mar 2026 08:39:10 +0800 (CST) From: Andy Fan To: PostgreSQL Hackers Subject: Re: raise ERROR between EndPrepare and PostPrepare_Locks causes ROLLBACK 2pc PAINC In-Reply-To: <87341p7dc4.fsf@163.com> (Andy Fan's message of "Tue, 24 Mar 2026 18:04:43 +0800") References: <87341p7dc4.fsf@163.com> User-Agent: mu4e 1.14.0-pre2; emacs 30.2 Date: Wed, 25 Mar 2026 08:39:07 +0800 Message-ID: <87h5q468us.fsf@163.com> MIME-Version: 1.0 Content-Type: text/plain X-CM-TRANSID: PCgvCgAnQs+rLsNp5cy+Sg--.20204S3 X-Coremail-Antispam: 1Uf129KBjvdXoWrZrW3Xw1DAFWkWw1fXryUAwb_yoW3trb_ua n5GFyxGF45ZFsxK34rCr4UGF4qqr4qkry8W3yUC3W2yF1Svw4rW3ykZ39xAF1xXrZYqFs8 Kr17Jana9w429jkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUvcSsGvfC2KfnxnUUI43ZEXa7sRuNt47UUUUU== X-Originating-IP: [101.227.46.165] X-CM-SenderInfo: x2klx3xlid0iqsrtqiywtou0bp/xtbC4xADVmnDLrCW6AAA3s List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andy Fan writes: > 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. I found a similar but not exactly same case at 2014 [1] which might be helpful to recall a boarder understanding on this area. [1] https://www.postgresql.org/message-id/534AF601.1030007%40vmware.com -- Best Regards Andy Fan