Kevin Grittner wrote:
> >>> Bruce Momjian <bruce@momjian.us> 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.
> >
> > You can see the resulting text here:
> >
> >
> http://momjian.us/tmp/pgsql/transaction-iso.html#XACT-READ-COMMITTED
>
> So READ COMMITTED allows a single SQL statement to see and act upon a
> database state which represents partial completion of a concurrent
> database transaction? I'm not sure whether the SQL spec explicitly
> prohibits that, but it does seem surprising and potentially dangerous.
We often get away with justifying our current behavior by saying the
behavior is correct if we see only the pre-update or post-update
snapshot. The only way I can see to show a clear failure is to see
parts of both, as I showed in the example.
> At a minimum, the documentation you suggest seems wise. If that can
> be prevented, I think it should be. Seriously, this would justify
> giving up the guarantee that serialization failures can't happen in
> PostgreSQL in READ COMMITTED mode. That guarantee is not required by
> the standard, is not present in many databases, and to me it is less
> important that accurate results.
We find adding documentation often helps people see the behavior more
clearly, even if we don't have a fix for it.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
