Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch

Tom Lane wrote:
> > At one point I was thinking "combo". but "composite" sounds good.
>
> I like "combo" --- nice and short.
>
> >> 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.
>
> Yeah, that's more or less what I was thinking. The problem is that the
> composite CID isn't going to be enough info to tell you *where* you have
> to put things back. And we don't want to try to remember per-row state
> in memory. Is there a way to generalize either the composite CID or the
> MultiXact mechanism to support this situation without that?

Uh, well, hmmm.

The way combo cid is supposed to work is that you are deleting a row
created in your same transaction by a previous command id, so you look
in the combo cid array to see if a match for that pair exists --- if
not, you create a new entry and put the two cids on it.

So, with the combo lock cid, you do the same process, and lookups of who
holds the lock looks at the cid combo, and if the second subtransaction
was aborted, the first one is the lock holder. If you again lock the
row, you create a new combo cid and use the original cid there because
the second cid was aborted.

I don't see how any of this is per-row for locks anymore than it is
per-row for insert/delete.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +