Bruce Momjian wrote:
> Tom Lane wrote:
> >
> > Another issue that we need to think about before we go too far with this
> > is the problem that we punted on before 8.2 release: how to deal with
> > rolling back an upgrade of a row-level lock from shared to exclusive
> > within a subtransaction. I'm a bit nervous about committing to merging
> > cmin and cmax before we have an idea how we're going to solve that ---
> > it might foreclose a solution. Or maybe we could piggyback on phantom/
> > composite/whatever CIDs to solve it, which would be great, but let's
> > try to sketch out a solution now.
>
> Good point. Right now we put our new cid on top of the old lock cid,
> making rollback impossible to the old lock. What if instead of
> overwriting our old cid with a new one, we create a composite cid, and
> if we roll back, we look up the composite pair and put the old cid back.
> It would only work with two cids, but that seems sufficient.
This starts to look awfully similar to MultiXactIds. And probably using
such a mechanism would allow you to "rollback" any number of row locks:
take the current membersoof the "multicid", substract the one that
rolled back and use that as new multicid. The main difference is that
you'd need to store both the locker Cid and the mode (shared/exclusive).
The other difference is that multicids can be stored locally to a
backend, no need to have SLRUs etc.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
