Date: Thu, 19 Aug 2021 12:37:58 -0400
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Subject: reporting TID/table with corruption error
Message-ID: <202108191637.oqyzrdtnheir@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="noofub6pisklu2cx"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/202108191637.oqyzrdtnheir%40alvherre.pgsql>
Precedence: bulk


--noofub6pisklu2cx
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

A customer recently hit this error message:

ERROR:  t_xmin is uncommitted in tuple to be updated

This was not very informative, so without any clues, we had to let it
go.  But it did occur to me that we can improve this message so that we
know details such as the TID and the relation that caused the issue, so
that if it ever occurs again we can at least look at the WAL stream for
anything affecting the tuple, maybe it'd help to understand the problem.

So I propose the following patch.

-- 
Álvaro Herrera

--noofub6pisklu2cx
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: attachment; filename="report-tuple.patch"

diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index beb8f20708..9befe012a9 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -424,7 +424,11 @@ tuple_lock_retry:
 					if (TransactionIdIsValid(SnapshotDirty.xmin))
 						ereport(ERROR,
 								(errcode(ERRCODE_DATA_CORRUPTED),
-								 errmsg_internal("t_xmin is uncommitted in tuple to be updated")));
+								 errmsg_internal("t_xmin %u is uncommitted in tuple (%u,%u) to be updated in table \"%s\"",
+												 SnapshotDirty.xmin,
+												 ItemPointerGetBlockNumber(&tuple->t_self),
+												 ItemPointerGetOffsetNumber(&tuple->t_self),
+												 RelationGetRelationName(relation))));
 
 					/*
 					 * If tuple is being updated by other transaction then we

--noofub6pisklu2cx--