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