...as well as another bug described below.
So, Mark, you can use select order by for update now,
but be aware that such queries may return unordered
data if sort-keys will be changed by concurrent xactions.
My hands are mostly away from sources now, though I still
get Assert in vacuum (FreeBSD 2.2.6) when run Hiroshi test.
Vadim
======================= CVS log message ==================
1. Fix for elog(ERROR, "EvalPlanQual: t_xmin is uncommitted ?!") and possibly for other cases too: DO NOT cache
statusof transaction in unknown state (i.e. non-committed and non-aborted ones) Example: T1 reads row
updated/insertedby running T2 and cache T2 status. T2 commits. Now T1 reads a row updated by T2 and with
HEAP_XMAX_COMMITTED in t_infomask (so cached T2 status is not changed). Now T1 EvalPlanQual gets updated row version
withoutHEAP_XMIN_COMMITTED -> TransactionIdDidCommit(t_xmin) and TransactionIdDidAbort(t_xmin) return FALSE and T2
decidesthat t_xmin is not committed and gets ERROR above. It's too late to find more smart way to handle such cases
andso I just changed xact status caching and got rid TransactionIdFlushCache() from code. Changed: transam.c,
xact.c,lmgr.c and transam.h - last three just because of TransactionIdFlushCache() is removed.
2. heapam.c:
T1 marked a row for update. T2 waits for T1 commit/abort. T1 commits. T3 updates the row before T2 locks row page.
NowT2 sees that new row t_xmax is different from xact id (T1) T2 was waiting for. Old code did Assert here. New one
goesto HeapTupleSatisfiesUpdate. Obvious changes too.
