On 31 October 2012 19:35, Noah Misch <noah@leadboat.com> wrote:
> On Mon, Oct 29, 2012 at 08:18:33AM -0400, Kevin Grittner wrote:
>> Andres Freund wrote:
>> > On Sunday, October 28, 2012 11:47:16 PM Simon Riggs wrote:
>> >> Andres Freund <andres@2ndquadrant.com> wrote:
>>
>> >>> * Is it ok to make FOR UPDATE somewhat weaker than before? In 9.2
>> >>> and earlier you could be sure that if you FOR UPDATE'ed a row you
>> >>> could delete it. Unless I miss something now this will not block
>> >>> somebody else acquiring a FOR KEY SHARE lock, so this guarantee
>> >>> is gone.
>> >>
>> >> Yes, that is exactly the point of this.
>> >
>> > The point is the introduction of a weaker lock level which can be
>> > used by the ri triggers. I don't see any imperative that the
>> > semantics of the old lock level need to be redefined. That just
>> > seems dangerous to me.
>>
>> I agree with Andres here -- the new lock level is needed within RI
>> triggers, and we might as well expose it for application programmer
>> use (with proper documentations), but there's no reason to break
>> existing application code by making the semantics of SELECT FOR
>> UPDATE less strict than they were before. Let's keep that term
>> meaning exactly the same thing if we can, and use new names for the
>> new levels.
>
> +1. I had not considered this angle during previous reviews, but I agree with
> Andres's position. Since this patch does not strengthen the strongest tuple
> lock relative to its PostgreSQL 9.2 counterpart, that lock type should
> continue to use the syntax "FOR UPDATE". It will come to mean "the lock type
> sufficient for all possible UPDATEs of the row".
So we have syntax
FOR NON KEY UPDATE
FOR KEY UPDATE
KEY is the default, so FOR UPDATE is a synonym of FOR KEY UPDATE
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
