From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: WHERE CURRENT OF behaviour is not what's documented |
Date: | 2013-09-18 12:27:48 |
Message-ID: | 20130918122748.GA22364@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2013-09-18 12:31:26 | Re: psql should show disabled internal triggers |
Previous Message | Boszormenyi Zoltan | 2013-09-18 12:23:19 | WHERE CURRENT OF behaviour is not what's documented |