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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
