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

Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> Packed doesn't seem to have quite the right connotation either --- it
>> sounds like it means there are two separable fields in the CID value.
>> 
>> Maybe "composite cid"?

> 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?
        regards, tom lane