Jeff Davis wrote:
> On Wed, 2009-02-04 at 11:11 -0500, Bruce Momjian wrote:
> > Well, with no one replying, :-(, I went ahead and added to the Read
> > Committed section of our manual to show a simple case where our read
> > committed mode produces undesirable results. I also did a little
> > cleanup at the same time.
>
> We could also add something to the SELECT docs. For example:
>
> "FOR SHARE/UPDATE causes the SELECT to behave with the same isolation
> semantics as UPDATE or DELETE. You may see results that are impossible
> to see using SELECT without FOR UPDATE/SHARE. See Chapter 13."
>
> The current SELECT FOR UPDATE/SHARE docs do address the issue, but most
> of the discussion revolves around locking semantics, not isolation. I
> think the important missing piece is "...you may see results that are
> impossible to see using SELECT...".
Well, I think the big issue is that the problem I found was in no way
unique to SELECT FOR UPDATE/SHARE; UPDATE and DELETE have the same
problem, as illustrated, so mentioning it only for SELECT FOR UPDATE
seems odd. I think the existing SELECT FOR UPDATE/SHARE mentions are
unique to SELECT FOR UPDATE/SHARE and should remain.
> I've learned a few things during this discussion, but the most
> surprising thing to me was that FOR SHARE/UPDATE really change the
> isolation semantics, and that it's more like UPDATE than SELECT.
I made that clearer in the read committed docs than it was in the past,
so hopefully that will help.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +