From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, npboley(at)gmail(dot)com, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: More FOR UPDATE/FOR SHARE problems |
Date: | 2009-02-04 17:41:14 |
Message-ID: | 1233769274.29523.25.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-02-04 17:44:37 | Re: add_path optimization |
Previous Message | Kevin Grittner | 2009-02-04 17:37:38 | Re: add_path optimization |