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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch
Date: 2007-02-08 20:00:03
Message-ID: 15966.1170964803@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

[ time to move this thread to -hackers ]

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> Alvaro Herrera <alvherre(at)commandprompt(dot)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"?

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephan Szabo 2007-02-08 20:24:19 Re: referential Integrity and SHARE locks
Previous Message Alvaro Herrera 2007-02-08 19:59:37 Re: Proposal: Commit timestamp

Browse pgsql-patches by date

  From Date Subject
Next Message Pavel Stehule 2007-02-08 20:03:09 Re: TM formating patch
Previous Message korryd 2007-02-08 19:40:53 Re: [pgsql-patches] Fixed shared_preload_libraries onWin32