Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Ym5Z3-00028L-2K for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 19:16:33 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Ym5Z1-0000KD-JZ for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 19:16:31 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Ym5Yz-0000K2-L5 for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 19:16:29 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1Ym5Ys-00054D-N7 for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 19:16:28 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1Ym5Yn-00017Y-GZ; Sat, 25 Apr 2015 15:16:17 -0400 Date: Sat, 25 Apr 2015 15:16:17 -0400 From: Bruce Momjian To: "David G. Johnston" Cc: Kevin Grittner , Peter Eisentraut , "pgsql-docs@postgresql.org" Subject: Re: Add a new table for Transaction Isolation? Message-ID: <20150425191617.GC17791@momjian.us> References: <1691752982.3879494.1429908040587.JavaMail.yahoo@mail.yahoo.com> <20150425180249.GA17791@momjian.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org On Sat, Apr 25, 2015 at 11:33:36AM -0700, David G. Johnston wrote: > On Sat, Apr 25, 2015 at 11:02 AM, Bruce Momjian wrote: > > On Fri, Apr 24, 2015 at 08:40:40PM +0000, Kevin Grittner wrote: > > And, for reasons given above, I really question whether such a > > table doesn't do more harm than good.  Even those citing the paper > > by Berenson, et al., often miss the text in *that* paper about what > > the actual definition of serializable transactions in the standard > > is, and instead focus on the quick-to-read tables of how the > > misinterpretation of serializable transactions based on the > > standard's table of phenomena (which the paper dubs "ANOMALY > > SERIALIZABLE") differs from truly serializable behavior. > > > > People do love tables like this, which makes providing them > > tempting; but when a short, clean table is available they often > > seem less inclined to take the trouble to read the real information > > the table summarizes -- and they come away with distorted and > > incorrect ideas about the subject matter. > > I don't think we can abandon the table --- people have enough trouble > figuring this out, including me, and without the table, it will be even > harder. > > What I have done is to add two rows and one column to the table, and > changed the surrounding text to more clearly reference the table.  You > can see the output here, and the SGML patch is attached: > >         http://momjian.us/expire/transaction-iso.html > > > Need to add "Serialization Anomalies" to the previous section's definitions > list. Uh, I am afraid the problem is that "Serialization Anomalies" is kind of defined by the standard in an odd way that is specific to serializable mode, I think. Kevin, is that true? > ​Pondering whether something like: "Possible (not in PG)" and avoiding the > additional rows would make reading the table easier. Uh, that's an idea. I thought visually having two separate lines was cleaner. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs