From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: foreign key locks, 2nd attempt |
Date: | 2011-11-10 21:19:59 |
Message-ID: | 201111102119.pAALJxM27424@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera wrote:
>
> Excerpts from Bruce Momjian's message of jue nov 10 16:59:20 -0300 2011:
> > Alvaro Herrera wrote:
> > > Hello,
> > >
> > > After some rather extensive rewriting, I submit the patch to improve
> > > foreign key locks.
> > >
> > > To recap, the point of this patch is to introduce a new lock tuple mode,
> > > that lets the RI code obtain a lighter lock on tuples, which doesn't
> > > conflict with updates that do not modify the key columns.
> >
> > What kind of operations benefit from a non-key lock like this?
>
> I'm not sure I understand the question.
>
> With this patch, a RI check does "SELECT FOR KEY SHARE". This means the
> tuple is locked with that mode until the transaction finishes. An
> UPDATE that modifies the referenced row will not conflict with that lock.
>
> An UPDATE that modifies the key columns will be blocked, just as now.
> Same with a DELETE.
OK, so it prevents non-key data modifications from spilling to the
referred rows --- nice.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-11-10 21:25:46 | LOCK_DEBUG is busted |
Previous Message | Dimitri Fontaine | 2011-11-10 21:19:02 | Re: Syntax for partitioning |