Skip site navigation (1) Skip section navigation (2)

Re: foreign key locks

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Kevin Grittner <kgrittn(at)mail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: foreign key locks
Date: 2012-11-05 22:22:17
Message-ID: m2zk2vg06e.fsf@2ndQuadrant.fr (view raw or flat)
Thread:
Lists: pgsql-hackers
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> FOR NON KEY UPDATE
>> FOR KEY UPDATE
>> 
>> KEY is the default, so FOR UPDATE is a synonym of FOR KEY UPDATE
>
> Not really sure about the proposed syntax, but yes clearly we need some
> other syntax to mean "FOR NON KEY UPDATE".  I would rather keep FOR
> UPDATE to mean what I currently call FOR KEY UPDATE.  More proposals for
> the other (weaker) lock level welcome (but if you love FOR NON KEY
> UPDATE, please chime in too)

FOR ANY UPDATE, synonym of FOR UPDATE
FOR KEY UPDATE, optimized version, when it applies to your case

I also tend to think that we should better not change the current
meaning of FOR UPDATE and have it default to FOR ANY UPDATE.

Unless it's easy to upgrade from ANY to KEY, and do that automatically
at the right time, but I fear there lie dragons (or something).

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


In response to

pgsql-hackers by date

Next:From: Daniel FarinaDate: 2012-11-05 22:24:10
Subject: Re: Synchronous commit not... synchronous?
Previous:From: Andrew DunstanDate: 2012-11-05 22:15:41
Subject: Re: Deprecations in authentication

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group