Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Ym61M-0003db-Al for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 19:45:48 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Ym61L-0004Ae-N5 for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 19:45:47 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Ym61J-0004AV-3n for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 19:45:45 +0000 Received: from nm7-vm4.bullet.mail.ne1.yahoo.com ([98.138.91.167]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Ym61D-0004wq-LU for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 19:45:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ymail.com; s=s2048; t=1429991136; bh=gZSx7o+tXvgBIp73cFYIxZve5GhabqvVPize/aRoJW4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=abdoSSopjyzF7NAjwUmWIM7R0M/Us+Xm7R7pfn1alSm7xk6enFJAa0A2Ofh9mmQxYEh0ntP7eUX51HUjsBH39qDQXzPaMG5RtExjYRFnsgBclY4zEr0urVHmW/hE/OtB1VzAiDbIkWYI5TzbyUKoM+2mvQUTzFJCVeTnpiQpQDFREZz+kCuSpRhCyPM/oZfwvEtMycgHROX2rS7SQvXSvCgfSfAtRY4vR6YkWGNnRYzyf11p3gf5dIRo+mgg0CVdClwk9xh+dptojhOJPha/PKLCM2+WiywimVytK47q6rmZCFXKv8Mj7z4m/hxG9Rk9Gw8FRP8fC0LNuVBnz/0ekA== Received: from [98.138.100.113] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 25 Apr 2015 19:45:36 -0000 Received: from [98.138.89.248] by tm104.bullet.mail.ne1.yahoo.com with NNFMP; 25 Apr 2015 19:45:36 -0000 Received: from [127.0.0.1] by omp1040.mail.ne1.yahoo.com with NNFMP; 25 Apr 2015 19:45:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 807104.3737.bm@omp1040.mail.ne1.yahoo.com X-YMail-OSG: JDvwwScVM1l0jE8VCTmEKF6PqKxb4wum0bXz8PZIfNgNSQ6mHgl9Bk6gVQKthQ1 igFbTYDbMiOyaNz8IdgDB2W8Fk0T7Byplzzs0xhtFXO6kmIR6mT2M5wA_1gByhdnC8blw5vW9UP7 Axa5df1AfTrgZ.vOpTrH8nciOVVSayyMOkpoSSYatw34.I4zmWls.41Rpj4uXbb4_Ujg4xuf2gB4 eEx1etIPXDR0EneK5iu6IT.u2PMqiWl7tTxzzN3ab9XPRyBqCAE79qDWRWpqeTqxwVh.TJXs9yGG IEqGot5hzFun28jmg7flEBhK3fG_Ixd32VM1bBeizMWKPN4pjqV1g2EVXl7OREnN2hYsCf5u9Izb shz7VvLtOmw5DZQ_2Z2zI3L.Zgk_QlkoUIxItPXw.SIQbwX9FzktDVfs6zz65VYskXBXfoo8U0W4 BhSz3YGYopQzsZ0soxinyGdR26h1rqNCFbcvl9sXhhO6kas6GCmudjlqSD8pfF_ZODIIKgzpn5bB 0KfX_TzWoreh_XgMvjqMoDw-- Received: by 98.138.105.250; Sat, 25 Apr 2015 19:45:36 +0000 Date: Sat, 25 Apr 2015 19:45:35 +0000 (UTC) From: Kevin Grittner Reply-To: Kevin Grittner To: Bruce Momjian , "David G. Johnston" Cc: Peter Eisentraut , "pgsql-docs@postgresql.org" Message-ID: <112988831.4359293.1429991135817.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150425191617.GC17791@momjian.us> References: <20150425191617.GC17791@momjian.us> Subject: Re: Add a new table for Transaction Isolation? MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Length: 1494 X-Pg-Spam-Score: -2.0 (--) 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 Bruce Momjian wrote: > On Sat, Apr 25, 2015 at 11:33:36AM -0700, David G. Johnston wrote: >> 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? They never use the word anomaly (or its plural) in the standard (even though it is prevalent in the academic literature). See my earlier email for examples of how the standard describes the issue, but basically it just boils down to saying that the effects of concurrent execution of a set of serializable transactions must be consistent with some one-at-a-time execution order. We could perhaps have the column header say "Non-Serializable Behavior" or some such; but I think we need to define whatever term we use for the new column header. >> =E2=80=8BPondering 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. I think one row per transaction isolation level, with three possible values per cell, would be the cleanest. I have been trying to think of alternatives for the three values, but have not come up with anything better than David's suggestion. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company --=20 Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs