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". -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
