On 2013-09-18 14:23:19 +0200, Boszormenyi Zoltan wrote: > Hi, > > I have experimented with cursors a little and found that the part about FOR > SHARE/FOR UPDATE in > > http://www.postgresql.org/docs/9.2/interactive/sql-declare.html > > i.e. the "sensitive cursor" is not what actually happens. BTW, 9.3 has the > same contents for the same page. > > " > If the cursor's query includes FOR UPDATE or FOR SHARE, then returned rows > are locked at the time they are first fetched, in the same way as for a > regular SELECT > <http://www.postgresql.org/docs/9.3/interactive/sql-select.html> command > with these options. In addition, the returned rows will be the most > up-to-date versions; therefore these options provide the equivalent of what > the SQL standard calls a "sensitive cursor". (Specifying INSENSITIVE > together with FOR UPDATE or FOR SHARE is an error.) > " > > The statement that the "most up-to-date versions of the rows are returned" > doesn't reflect the reality anymore:
I think it's not referring to the behaviour inside a single session but across multiple sessions. I.e. when we follow the ctid chain of a tuple updated in a concurrent session. Greetings, Andres Freund -- Andres Freund 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
