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
epq_locktuple.v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers