On 31 October 2012 19:35, Noah Misch <n...@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 <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
