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

From Bruce Momjian
Subject Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch
Date
Msg-id 200702082027.l18KRVG00708@momjian.us
Whole thread Raw
In response to Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Tom Lane wrote:
> [ time to move this thread to -hackers ]
> 
> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> Alvaro Herrera <alvherre@commandprompt.com> writes:
> >>> Heikki Linnakangas wrote:
> >>>> Tom Lane wrote:
> >>>>> BTW, I don't care much for the terminology "phantom cid" ... there's
> >>>>> nothing particularly "phantom" about them, seeing they get onto disk.
> >>>>> Can anyone think of a better name?  The best I can do offhand is
> >>>>> "merged cid" or "cid pair", which aren't inspiring. 
> 
> >>>> MultiCid, like the MultiXacts? Maybe not, they're quite different beasts...
> 
> >>> Dual cid?  Double cid?
> 
> >> "Double cid" doesn't sound too bad.  Another thought that just came to
> >> mind is "cid interval" or some variant of that.
> 
> > I don't like "double ctid" because it is really just one ctid, but
> > represents two.  I am thinking "packed ctid" is the right wording.  It
> > doesn't have the same impact as "phantom", but it is probably better.
> 
> 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.

> 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.

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: referential Integrity and SHARE locks
Next
From: Marc Munro
Date:
Subject: Re: referential Integrity and SHARE locks