Re: FOR KEY LOCK foreign keys

From: Noah Misch <noah(at)leadboat(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Subject: Re: FOR KEY LOCK foreign keys
Date: 2011-02-11 18:17:59
Message-ID: 20110211181759.GC30425@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 11, 2011 at 02:15:20PM -0300, Alvaro Herrera wrote:
> Excerpts from Noah Misch's message of vie feb 11 04:13:22 -0300 2011:
> > On Thu, Jan 13, 2011 at 06:58:09PM -0300, Alvaro Herrera wrote:
> > > 3. The original tuple needs to be marked with the Cmax of the locking
> > > command, to prevent it from being seen in the same transaction.
> >
> > Could you elaborate on this requirement?
>
> Consider an open cursor with a snapshot prior to the lock. If we leave
> the old tuple as is, the cursor would see that old tuple as visible.
> But the locked copy of the tuple is also visible, because the Cmax is
> just a locker, not an updater.

Thanks. Today, a lock operation leaves t_cid unchanged, and an update fills its
own cid into Cmax of the old tuple and Cmin of the new tuple. So, the cursor
would only see the old tuple. What will make that no longer sufficient?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2011-02-11 18:18:58 Re: Debian readline/libedit breakage
Previous Message Stephen Frost 2011-02-11 18:13:27 Re: Debian readline/libedit breakage