src/backend/access/heap/README.tuplock says we do this...
LockTuple()
XactLockTableWait()
mark tuple as locked by me
UnlockTuple()
only problem is we don't... because EvalPlanQualFetch() does this
XactLockTableWait()
LockTuple()
If README.tuplock's reasons for the stated lock order is correct then
it implies that EvalPlanQual updates could be starved indefinitely,
which is probably bad.
It might also be a bug of more serious nature, though no bug seen.
This was found while debugging why wait_event not set correctly.
In any case, I can't really see any reason for this coding in
EvalPlanQual and it isn't explained in comments. Simply removing the
wait allows the access pattern to follow the documented lock order,
and allows regression tests and isolation tests to pass without
problem. Perhaps I have made an error there.
Thoughts?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
