Re: correction

On Fri, May 13, 2022 at 2:49 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
wrote:

> On Fri, 2022-05-13 at 16:36 -0400, Bruce Momjian wrote:
> > On Wed, May 11, 2022 at 12:36:11PM +0200, Laurenz Albe wrote:
> > > On Wed, 2022-05-11 at 00:33 +0000, PG Doc comments form wrote:
> > > > The following documentation comment has been logged on the website:
> > > >
> > > > Page: https://www.postgresql.org/docs/14/transaction-iso.html
> > > > Description:
> > > >
> > > > in this page:
> https://www.postgresql.org/docs/14/transaction-iso.html
> > > >
> > > > under the Table 13.1 section, if we search for "phantom reads.
> Stricter
> > > > behavior is permitted by the SQL standard", do we mean "Looser
> behaviour"?
> > >
> > > What is meant is "The SQL standard allows an implementation to
> implement
> > > stricter behavior than required by the standard; it only defines the
> things
> > > that are *not* allowed to happen at a certain isolation level. So it
> is for
> > > example fine for PostgreSQL not to allow dirty reads in READ
> UNCOMMITTED
> > > isolation level."
> > >
> > > Perhaps this could be rewritten to be clearer; it is indeed easy to
> > > misunderstand that sentence.
> >
> > How is this attached patch's wording?
> >
> > diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
> > index 341fea524a..244694b07f 100644
> > --- a/doc/src/sgml/mvcc.sgml
> > +++ b/doc/src/sgml/mvcc.sgml
> > @@ -277,8 +277,8 @@
> >
> > <para>
> > The table also shows that PostgreSQL's Repeatable Read
> implementation
> > - does not allow phantom reads. Stricter behavior is permitted by the
> > - SQL standard: the four isolation levels only define which phenomena
> > + does not allow phantom reads. The SQL standard allows more
> restrictive
> > + behavior: the four isolation levels only define which phenomena
> > must not happen, not which phenomena <emphasis>must</emphasis>
> happen.
> > The behavior of the available isolation levels is detailed in the
> > following subsections.
>
> I think that suffers from the same problem: izt sounds like the standard
> allows
> stricter behavior than PostgreSQL.
>
> How about:
>
> The table also shows that PostgreSQL's Repeatable Read implementation
> does not allow phantom reads. That is fine, because the SQL standard
> only
> specifies which anomalies must <emphasis>not</enphasis> occur at a
> certain
> isolation level. It is no problem if an implementation provides higher
> guarantees than required.
> The behavior of the available isolation levels is detailed in the
> following subsections.
>
>
>
How about this?

I really dislike the table having "Allow, but" - it's not allowed and
having the reader have to interpret "but" to understand the "not possible"
aspect of the cell seems unnecessary. The "in PG" qualification and a note
makes it perfectly clear where we deviate from the standard - on the binary
option.

I also suggest (but did not implement) taking out the mention of the RR
exception from here and just leaving the main section where we repeat for a
second time what is self-evident from reading the table (so, three mentions
of this implementation choice):

"This is a stronger guarantee than is required by the SQL standard for this
isolation level, and prevents all of the phenomena described in Table 13.1
except for serialization anomalies. As mentioned above, this is
specifically allowed by the standard, which only describes the minimum
protections each isolation level must provide."

David J.

<entry>
- Allowed, but not in PG
+ Not possible in PG
</entry>
<entry>
Possible
@@ -238,7 +238,7 @@
Not possible
</entry>
<entry>
- Allowed, but not in PG
+ Not possible in PG
</entry>
<entry>
Possible
@@ -266,6 +266,12 @@
</tgroup>
</table>

+ <para>
+ Two entries in the above table are qualified by "in PG". For these,
+ the SQL standard deems the corresponding anomaly possible at that
+ isolation level but permits implementations to make it impossible.
+ </para>