On 2012-11-14 13:27:26 -0300, Alvaro Herrera wrote: > Alvaro Herrera wrote: > > > > * In heap_lock_tuple's XMAX_IS_MULTI case > > > > > > [snip] > > > > > > why is it membermode > mode and not membermode >= mode? > > > > Uh, that's a bug. Fixed. As noticed in the comment above that snippet, > > there was a deadlock possible here. Maybe I should add a test to ensure > > this doesn't happen. > > Done: > https://github.com/alvherre/postgres/commit/df2847e38198e99f57e52490e1e9391ebb70d770 > > (I don't think this is worth a v24 submission).
One more observation: /* * Get and lock the updated version of the row; if fail, return NULL. */ - copyTuple = EvalPlanQualFetch(estate, relation, LockTupleExclusive, + copyTuple = EvalPlanQualFetch(estate, relation, LockTupleNoKeyExclusive, That doesn't seem to be correct to me. Why is it ok to acquire a potentially too low locklevel here? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers