Bruce Momjian <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
