Relax overly strict sanity check for upgraded ancient databases

alvherre · alvherre · commit 0ddaaa4cf4ff · 2018-03-01T18:07:46.000-03:00
Commit 4800f16 added some sanity checks to ensure we don't accidentally corrupt data, but in one of them we failed to consider the effects of a database upgraded from 9.2 or earlier, where a tuple exclusively locked prior to the upgrade has a slightly different bit pattern. Fix that by using the macro that we fixed in commit 74ebba8 for similar situations. Reported-by: Alexandre Garcia Reviewed-by: Andres Freund Discussion: https://postgr.es/m/CAPYLKR6yxV4=pfW0Gwij7aPNiiPx+3ib4USVYnbuQdUtmkMaEA@mail.gmail.com Andres suspects that this bug may have wider ranging consequences, but I couldn't find anything.
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
@@ -6783,7 +6783,7 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple,
 			 * independent of committedness, since a committed lock holder has
 			 * released the lock).
 			 */
-			if (!(tuple->t_infomask & HEAP_XMAX_LOCK_ONLY) &&
+			if (!HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask) &&
 				TransactionIdDidCommit(xid))
 				ereport(ERROR,
 						(errcode(ERRCODE_DATA_CORRUPTED),
