Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nygQa-0000mD-O7 for pgsql-docs@arkaria.postgresql.org; Tue, 07 Jun 2022 21:07:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nygQZ-00051e-J2 for pgsql-docs@arkaria.postgresql.org; Tue, 07 Jun 2022 21:07:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nygQZ-00051F-Bi for pgsql-docs@lists.postgresql.org; Tue, 07 Jun 2022 21:07:51 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nygQU-0005jN-Ip for pgsql-docs@lists.postgresql.org; Tue, 07 Jun 2022 21:07:50 +0000 Received: from bruce by momjian.us with local (Exim 4.94.2) (envelope-from ) id 1nygQP-000hcL-ID; Tue, 07 Jun 2022 17:07:41 -0400 Date: Tue, 7 Jun 2022 17:07:41 -0400 From: Bruce Momjian To: Laurenz Albe Cc: akhilhello@gmail.com, pgsql-docs@lists.postgresql.org Subject: Re: correction Message-ID: References: <165222922369.669.10475917322916060899@wrigleys.postgresql.org> <179f4ffe247c3d6c0938217ef85948bcebb97bdb.camel@cybertec.at> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="VYHgR5/TVYmycq9K" Content-Disposition: inline In-Reply-To: <179f4ffe247c3d6c0938217ef85948bcebb97bdb.camel@cybertec.at> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --VYHgR5/TVYmycq9K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 13, 2022 at 11:49:09PM +0200, Laurenz Albe wrote: > 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 not 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 is this, attached? -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson --VYHgR5/TVYmycq9K Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="strict.diff" diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml index 341fea524a..112d6ce7a8 100644 --- a/doc/src/sgml/mvcc.sgml +++ b/doc/src/sgml/mvcc.sgml @@ -277,9 +277,10 @@ 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 - must not happen, not which phenomena must happen. + does not allow phantom reads. This is acceptable under the SQL + standard because the standard specifies which anomalies must + not occur at certain isolation levels; higher + guarantees are acceptable. The behavior of the available isolation levels is detailed in the following subsections. --VYHgR5/TVYmycq9K--