Alexandre Garcia wrote: > > > > Ooh. > > > > If you SELECT FOR UPDATE a tuple in 9.2, bit 0x0040 gets set in > > infomask, and nothing else. If you pg_upgrade and later try to freeze > > such a tuple, it will fail with the error reported. > > > > The correct test to use is HEAP_XMAX_IS_LOCKED_ONLY, which also tests > > for the above condition. > > > > I will verify this theory and push a patch shortly, if it proves > > correct. > > Oh good news :). I have my old 9.2 around if you need me to do more > testing on it. Not necessary -- I reproduced the problem (quite easily -- just SELECT FOR UPDATE a tuple in 9.2, then pg_upgrade, then VACUUM FREEZE the table in the upgraded server) and confirm that it doesn't happen in 9.6.6, happens in 9.6.8 (didn't try 9.6.7 but code is the same as 9.6.8), and is fixed with the attached patch. Will push soon ... probably tomorrow as I have to leave the building now. Cheers -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 4ecaa6cdc041d9f44d54f9d56588ea73c1c6f3c7 Mon Sep 17 00:00:00 2001 From: Alvaro Herrera <alvherre@xxxxxxxxxxxxxx> Date: Wed, 28 Feb 2018 20:16:35 -0300 Subject: [PATCH] Fix freeze xmax bug --- src/backend/access/heap/heapam.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c index 8a846e7dba..dc762f913d 100644 --- a/src/backend/access/heap/heapam.c +++ b/src/backend/access/heap/heapam.c @@ -6799,7 +6799,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), -- 2.11.0
