From david.g.johnston@gmail.com Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Yhr5m-000457-BH for pgsql-docs@arkaria.postgresql.org; Tue, 14 Apr 2015 03:00:50 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Yhr5k-0006I8-Nt for pgsql-docs@arkaria.postgresql.org; Tue, 14 Apr 2015 03:00:48 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Yhr5j-0006Hx-Mo for pgsql-docs@postgresql.org; Tue, 14 Apr 2015 03:00:47 +0000 Received: from mail-ie0-x22a.google.com ([2607:f8b0:4001:c03::22a]) by makus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Yhr5b-0006W9-QU for pgsql-docs@postgresql.org; Tue, 14 Apr 2015 03:00:45 +0000 Received: by iedfl3 with SMTP id fl3so5644743ied.1 for ; Mon, 13 Apr 2015 20:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IqP9qqNvsQYY7y5Vi5YeQY5RzPpEVLzHQfpe1pBj+zc=; b=TZCbx6hBvXF1N890/Qs6Egvgry//TVW+EnD5HayrciINwN41I03YgmpOtjNRdBanZy aBnOjnt/U60OOLmFRr58aSYeWXLwCifupvxEgN4eD6Gscmxd+CZHtTIZ70E/cP9hKtZJ vPuokPwHcb1i1WKrqSRedC4BVzKsRgat1t0Lj0xG9fOTy/FVR0Ana4Li6kszBdhCXMh8 vrcXBL77mH5n8RjwLWBu5fyDbf64fxdMYjZCWTZDYyJKd/ttaIJjZd3LCQMUz6PoKLGp uTBjgvLiIVQwjXWC0nQXqNIbjFncyPCa4U893bgwIC/Cl9iFJYUAqJhtnWYYgxWUKmWB vJLQ== MIME-Version: 1.0 X-Received: by 10.42.64.76 with SMTP id f12mr23040521ici.93.1428980438572; Mon, 13 Apr 2015 20:00:38 -0700 (PDT) Received: by 10.36.64.15 with HTTP; Mon, 13 Apr 2015 20:00:38 -0700 (PDT) Date: Mon, 13 Apr 2015 20:00:38 -0700 Message-ID: Subject: Add a new table for Transaction Isolation? From: "David G. Johnston" To: "pgsql-docs@postgresql.org" Content-Type: multipart/alternative; boundary=90e6ba3fd3876ea69d0513a66f50 X-Pg-Spam-Score: -2.7 (--) 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 --90e6ba3fd3876ea69d0513a66f50 Content-Type: text/plain; charset=UTF-8 http://www.postgresql.org/docs/9.4/static/transaction-iso.html Table 13-1 shows the SQL standard isolation levels and what is and is not guaranteed. Then the text goes on to explain how our implementation differs from that table. Is there any opposition to actually adding a similar table, 13-2, probably right after the paragraph, with the same columns, three rows, and the corresponding possible/not-possible cell values? David J. --90e6ba3fd3876ea69d0513a66f50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
http://www.postgresql.org/docs/9.4/static/transaction-= iso.html

Table 13-1 shows the= SQL standard isolation levels and what is and is not guaranteed.=C2=A0 The= n the text goes on to explain how our implementation differs from that tabl= e.=C2=A0 Is there any opposition to actually adding a similar table, 13-2, = probably right after the paragraph, with the same columns, three rows, and = the corresponding possible/not-possible cell values?

David J.

--90e6ba3fd3876ea69d0513a66f50-- From bruce@momjian.us Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YiYUr-0006C6-7l for pgsql-docs@arkaria.postgresql.org; Thu, 16 Apr 2015 01:21:37 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YiYUq-0003IJ-6Y for pgsql-docs@arkaria.postgresql.org; Thu, 16 Apr 2015 01:21:36 +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 1YiYUp-0003IC-Bd for pgsql-docs@postgresql.org; Thu, 16 Apr 2015 01:21:35 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YiYUk-00065x-I2 for pgsql-docs@postgresql.org; Thu, 16 Apr 2015 01:21:33 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1YiYUi-0003x0-BN; Wed, 15 Apr 2015 21:21:28 -0400 Date: Wed, 15 Apr 2015 21:21:28 -0400 From: Bruce Momjian To: "David G. Johnston" Cc: "pgsql-docs@postgresql.org" Subject: Re: Add a new table for Transaction Isolation? Message-ID: <20150416012128.GB1672@momjian.us> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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 Mon, Apr 13, 2015 at 08:00:38PM -0700, David G. Johnston wrote: > http://www.postgresql.org/docs/9.4/static/transaction-iso.html > > Table 13-1 shows the SQL standard isolation levels and what is and is not > guaranteed.  Then the text goes on to explain how our implementation differs > from that table.  Is there any opposition to actually adding a similar table, > 13-2, probably right after the paragraph, with the same columns, three rows, > and the corresponding possible/not-possible cell values? Yes, it does make sense to have a table that properly matches the Postgres implementation. Should I write a patch or would you like to? -- 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 From david.g.johnston@gmail.com Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YiYZB-0006Nt-Rh for pgsql-docs@arkaria.postgresql.org; Thu, 16 Apr 2015 01:26:05 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YiYZB-0003ph-BJ for pgsql-docs@arkaria.postgresql.org; Thu, 16 Apr 2015 01:26:05 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YiYZA-0003pX-Iz for pgsql-docs@postgresql.org; Thu, 16 Apr 2015 01:26:04 +0000 Received: from mail-ie0-x22d.google.com ([2607:f8b0:4001:c03::22d]) by makus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YiYZ7-0007Vc-5e for pgsql-docs@postgresql.org; Thu, 16 Apr 2015 01:26:02 +0000 Received: by iecrt8 with SMTP id rt8so28762569iec.0 for ; Wed, 15 Apr 2015 18:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GnUn0y9YAX66hdeuy9dJPEsJuSMuKa8f/5UQ76Q1aoI=; b=JMANAG0Csk9DPa56g1ZqHzDJRraSiQEGPxThc7li8cKylXWAc/3sCHeN7MfiujJ3Yx 4T0GX04zhLU+OgXRDyFTB0fFhj3msK7MDl/Cy/l64CWxa7ySCp95r8N1GRdsLutBin5x +MsP+vDNx4uhjFPB+6c5nDbd++ZjBi6RbgYQyZSTXvzrHiRpJEOF5/KsOYthsrw+DH7Y S5FGwtbQIfP4MuYfxPZewBHdrq7uIhP79B4h2mLjO+/qax0S4AsOZ9Cipv70CtM7CxLd jHkEJD9Kt96p4vn/Vm7h+gwWtNJYmVfvaua1SzsKJQ5SiE/DmSMWiz6cCixrdSHuT4kG 3FbA== MIME-Version: 1.0 X-Received: by 10.42.0.9 with SMTP id 9mr34870336ica.49.1429147560432; Wed, 15 Apr 2015 18:26:00 -0700 (PDT) Received: by 10.36.64.15 with HTTP; Wed, 15 Apr 2015 18:26:00 -0700 (PDT) In-Reply-To: <20150416012128.GB1672@momjian.us> References: <20150416012128.GB1672@momjian.us> Date: Wed, 15 Apr 2015 18:26:00 -0700 Message-ID: Subject: Re: Add a new table for Transaction Isolation? From: "David G. Johnston" To: Bruce Momjian Cc: "pgsql-docs@postgresql.org" Content-Type: multipart/alternative; boundary=001a11c3aa56ac01ed0513cd58c6 X-Pg-Spam-Score: -2.7 (--) 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 --001a11c3aa56ac01ed0513cd58c6 Content-Type: text/plain; charset=UTF-8 On Wednesday, April 15, 2015, Bruce Momjian wrote: > On Mon, Apr 13, 2015 at 08:00:38PM -0700, David G. Johnston wrote: > > http://www.postgresql.org/docs/9.4/static/transaction-iso.html > > > > Table 13-1 shows the SQL standard isolation levels and what is and is not > > guaranteed. Then the text goes on to explain how our implementation > differs > > from that table. Is there any opposition to actually adding a similar > table, > > 13-2, probably right after the paragraph, with the same columns, three > rows, > > and the corresponding possible/not-possible cell values? > > Yes, it does make sense to have a table that properly matches the > Postgres implementation. Should I write a patch or would you like to? > > I'll take a crack at it. David J. --001a11c3aa56ac01ed0513cd58c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, April 15, 2015, Bruce Momjian <bruce@momjian.us> wrote:
= On Mon, Apr 13, 2015 at 08:00:38PM -0700, David G. Johnston wrote:
> http://www.postgresql.org/docs/9.4/static/transactio= n-iso.html
>
> Table 13-1 shows the SQL standard isolation levels and what is and is = not
> guaranteed.=C2=A0 Then the text goes on to explain how our implementat= ion differs
> from that table.=C2=A0 Is there any opposition to actually adding a si= milar table,
> 13-2, probably right after the paragraph, with the same columns, three= rows,
> and the corresponding possible/not-possible cell values?

Yes, it does make sense to have a table that properly matches the
Postgres implementation.=C2=A0 =C2=A0Should I write a patch or would you li= ke to?


I'll take a crack at it.
David J.=C2=A0
--001a11c3aa56ac01ed0513cd58c6-- From david.g.johnston@gmail.com Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YjFoV-0006xt-Qx for pgsql-docs@arkaria.postgresql.org; Fri, 17 Apr 2015 23:36:47 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YjFoV-0003mA-6n for pgsql-docs@arkaria.postgresql.org; Fri, 17 Apr 2015 23:36:47 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YjFoT-0003lw-RC for pgsql-docs@postgresql.org; Fri, 17 Apr 2015 23:36:46 +0000 Received: from mail-ig0-x22c.google.com ([2607:f8b0:4001:c05::22c]) by makus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YjFoP-0008CH-Jn for pgsql-docs@postgresql.org; Fri, 17 Apr 2015 23:36:43 +0000 Received: by igblo3 with SMTP id lo3so24035832igb.1 for ; Fri, 17 Apr 2015 16:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y0dso9x7Rysk8WJDVtZOZlaC6O1wrP8NtyOF44YdgMI=; b=gg8XqUp2Kcl8BTBQj36iq5afAmfnimiCrHachp+NSsXmgZKKSXqmKrnULqJ1hb8CZv bj/MpNMtFEIM6WKLyHTOWeI4Os8rF84Qp4bT06TYIagTqM1VXoaL5ovgDaxVTa58ZYM4 QQJ4hXbi2kn3mGQ07xSQHZAFwR8p1fjEEIbKVGf21WIvzFJDundPdGrwoYuhJldpR1qI YZ1RMXJ5aBml1Suc63OTxLU/iv4Szc8pKQVkZnuy3V4Ul92+ktcdXah8+C7vf9MZr9WA 5CaEPpgxXxrsAEt36MxhGlSElskRLwj7HMDD71p7vsaDDGd++wNF4H2JXqY7aZj71N9O OYqQ== MIME-Version: 1.0 X-Received: by 10.50.41.8 with SMTP id b8mr6114763igl.38.1429313800867; Fri, 17 Apr 2015 16:36:40 -0700 (PDT) Received: by 10.36.64.15 with HTTP; Fri, 17 Apr 2015 16:36:40 -0700 (PDT) In-Reply-To: References: <20150416012128.GB1672@momjian.us> Date: Fri, 17 Apr 2015 16:36:40 -0700 Message-ID: Subject: Re: Add a new table for Transaction Isolation? From: "David G. Johnston" To: Bruce Momjian Cc: "pgsql-docs@postgresql.org" Content-Type: multipart/mixed; boundary=089e0116197a5fb21c0513f40d10 X-Pg-Spam-Score: -2.7 (--) 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 --089e0116197a5fb21c0513f40d10 Content-Type: multipart/alternative; boundary=089e0116197a5fb2170513f40d0e --089e0116197a5fb2170513f40d0e Content-Type: text/plain; charset=UTF-8 A bit of scope creep due to wanting to point out the obvious "RR and SER" are the same observation on the table. The main body for SER covers the fact as well though in a very technical way. I thought pointing out that examples are on the Wiki would be useful as well - not everyone would think to go there for additional information. No like though - just a pointer to it or the Internet generally. It is not obvious to me what means...I suspect 1=yes... David J. On Wed, Apr 15, 2015 at 6:26 PM, David G. Johnston < david.g.johnston@gmail.com> wrote: > On Wednesday, April 15, 2015, Bruce Momjian wrote: > >> On Mon, Apr 13, 2015 at 08:00:38PM -0700, David G. Johnston wrote: >> > http://www.postgresql.org/docs/9.4/static/transaction-iso.html >> > >> > Table 13-1 shows the SQL standard isolation levels and what is and is >> not >> > guaranteed. Then the text goes on to explain how our implementation >> differs >> > from that table. Is there any opposition to actually adding a similar >> table, >> > 13-2, probably right after the paragraph, with the same columns, three >> rows, >> > and the corresponding possible/not-possible cell values? >> >> Yes, it does make sense to have a table that properly matches the >> Postgres implementation. Should I write a patch or would you like to? >> >> > I'll take a crack at it. > > David J. > --089e0116197a5fb2170513f40d0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A bit of scope creep due to wanting to point out the ob= vious "RR and SER" are the same observation on the table.=C2=A0 T= he main body for SER covers the fact as well though in a very technical way= .

I thought pointing out that examples are on the Wiki= would be useful as well - not everyone would think to go there for additio= nal information.=C2=A0 No like though - just a pointer to it or the Interne= t generally.

It is not obvious to me what <table to= centry=3D"1"> means...I suspect 1=3Dyes...

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">David J.

On Wed, Apr 15, 2015 at 6:26 PM, David G. Johnston <david= .g.johnston@gmail.com> wrote:
On Wednesday, April 15, 2015, Bruce Momjian <bruce@momjian.us> wro= te:
On Mon, Apr 13, 2015 at 08:00:38PM -0= 700, David G. Johnston wrote:
> http://www.postgresql.org/docs/9.4/static/transactio= n-iso.html
>
> Table 13-1 shows the SQL standard isolation levels and what is and is = not
> guaranteed.=C2=A0 Then the text goes on to explain how our implementat= ion differs
> from that table.=C2=A0 Is there any opposition to actually adding a si= milar table,
> 13-2, probably right after the paragraph, with the same columns, three= rows,
> and the corresponding possible/not-possible cell values?

Yes, it does make sense to have a table that properly matches the
Postgres implementation.=C2=A0 =C2=A0Should I write a patch or would you li= ke to?


I'll take a crack at it.
<= div>
David J.=C2=A0

--089e0116197a5fb2170513f40d0e-- --089e0116197a5fb21c0513f40d10 Content-Type: text/plain; charset=US-ASCII; name="mvcc-isolationlevels-v1.diff" Content-Disposition: attachment; filename="mvcc-isolationlevels-v1.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i8m8ekbh0 ZGlmZiAtLWdpdCBhL2RvYy9zcmMvc2dtbC9tdmNjLnNnbWwgYi9kb2Mvc3Jj L3NnbWwvbXZjYy5zZ21sCmluZGV4IGY4OGIxNmUuLjUwMDIxMzggMTAwNjQ0 Ci0tLSBhL2RvYy9zcmMvc2dtbC9tdmNjLnNnbWwKKysrIGIvZG9jL3NyYy9z Z21sL212Y2Muc2dtbApAQCAtMTAwLDYgKzEwMCwxNCBAQAogICAgIHBoZW5v bWVuYSBjYXVzZWQgYnkgaW50ZXJhY3Rpb25zPykKICAgIDwvcGFyYT4KIAor ICA8cGFyYT4KKyAgIFRoZSBjb25jZXB0cyBjb3ZlcmVkIGluIHRoaXMgc2Vj dGlvbiBhcmUKKyAgIHByZXNlbnRlZCB3aXRob3V0IGV4YW1wbGVzIG9mIHRo ZSBiZWhhdmlvcnMgZGVzY3JpYmVkLiAgVGhlIGludGVybmV0LAorICAgaW5j bHVkaW5nIGFuZCBlc3BjaWFsbHkgdGhlIDxwcm9kdWN0bmFtZT5Qb3N0Z3Jl U1FMPC9wcm9kdWN0bmFtZT4gV2lraSwgaXMKKyAgIGFuIGV4Y2VsbGVudCBy ZXNvdXJjZSB0byBsZWFybiBtb3JlIGFib3V0IGNpcmN1bXN0YW5jZXMgdW5k ZXIgd2hpY2ggdGhlc2UKKyAgIGRhdGEgcGhlbm9tZW5hIG9jY3VyLCBhbmQg d2hhdCB0aGUgcmVzdWx0cyBsb29rIGxpa2Ugd2hlbiB0aGV5IGRvLgorICA8 L3BhcmE+CisKICAgIDxwYXJhPgogICAgIFRoZSBwaGVub21lbmEgd2hpY2gg YXJlIHByb2hpYml0ZWQgYXQgdmFyaW91cyBsZXZlbHMgYXJlOgogCkBAIC0x NTAsMTIgKzE1OCwxMiBAQAogICAgIDxpbmRleHRlcm0+CiAgICAgIDxwcmlt YXJ5PnRyYW5zYWN0aW9uIGlzb2xhdGlvbiBsZXZlbDwvcHJpbWFyeT4KICAg ICA8L2luZGV4dGVybT4KLSAgICBUaGUgZm91ciB0cmFuc2FjdGlvbiBpc29s YXRpb24gbGV2ZWxzIGFuZCB0aGUgY29ycmVzcG9uZGluZwotICAgIGJlaGF2 aW9ycyBhcmUgZGVzY3JpYmVkIGluIDx4cmVmIGxpbmtlbmQ9Im12Y2MtaXNv bGV2ZWwtdGFibGUiPi4KKyAgICBUaGUgZm91ciBTUUwgdHJhbnNhY3Rpb24g aXNvbGF0aW9uIGxldmVscywgYW5kIHRoZWlyIGNvcnJlc3BvbmRpbmcKKyAg ICBiZWhhdmlvcnMsIGFyZSBkZXNjcmliZWQgaW4gPHhyZWYgbGlua2VuZD0i bXZjYy1pc29sZXZlbC10YWJsZSI+LgogICAgPC9wYXJhPgogCiAgICAgPHRh YmxlIHRvY2VudHJ5PSIxIiBpZD0ibXZjYy1pc29sZXZlbC10YWJsZSI+Ci0g ICAgIDx0aXRsZT5TdGFuZGFyZCA8YWNyb255bT5TUUw8L2Fjcm9ueW0+IFRy YW5zYWN0aW9uIElzb2xhdGlvbiBMZXZlbHM8L3RpdGxlPgorICAgICA8dGl0 bGU+PGFjcm9ueW0+U1FMPC9hY3JvbnltPiBTdGFuZGFyZCBUcmFuc2FjdGlv biBJc29sYXRpb24gTGV2ZWxzPC90aXRsZT4KICAgICAgPHRncm91cCBjb2xz PSI0Ij4KICAgICAgIDx0aGVhZD4KICAgICAgICA8cm93PgpAQCAtMjU2LDYg KzI2NCw4OSBAQAogICAgPC9wYXJhPgogCiAgICA8cGFyYT4KKyAgICBUaGUg dGhyZWUgPHByb2R1Y3RuYW1lPlBvc3RncmVTUUw8L3Byb2R1Y3RuYW1lPiB0 cmFuc2FjdGlvbiBpc29sYXRpb24gbGV2ZWxzLCBhbmQgdGhlaXIgY29ycmVz cG9uZGluZworICAgIGJlaGF2aW9ycywgYXJlIGRlc2NyaWJlZCBpbiA8eHJl ZiBsaW5rZW5kPSJtdmNjLXBnc3FsLWlzb2xldmVsLXRhYmxlIj4uCisgICA8 L3BhcmE+CisKKyAgICA8dGFibGUgdG9jZW50cnk9IjEiIGlkPSJtdmNjLXBn c3FsLWlzb2xldmVsLXRhYmxlIj4KKyAgICAgPHRpdGxlPjxwcm9kdWN0bmFt ZT5Qb3N0Z3JlU1FMPC9wcm9kdWN0bmFtZT4gVHJhbnNhY3Rpb24gSXNvbGF0 aW9uIExldmVsczwvdGl0bGU+CisgICAgIDx0Z3JvdXAgY29scz0iNCI+Cisg ICAgICA8dGhlYWQ+CisgICAgICAgPHJvdz4KKyAgICAgICAgPGVudHJ5Pgor ICAgICAgICAgSXNvbGF0aW9uIExldmVsCisgICAgICAgIDwvZW50cnk+Cisg ICAgICAgIDxlbnRyeT4KKyAgICAgICAgIERpcnR5IFJlYWQKKyAgICAgICAg PC9lbnRyeT4KKyAgICAgICAgPGVudHJ5PgorICAgICAgICAgTm9ucmVwZWF0 YWJsZSBSZWFkCisgICAgICAgIDwvZW50cnk+CisgICAgICAgIDxlbnRyeT4K KyAgICAgICAgIFBoYW50b20gUmVhZAorICAgICAgICA8L2VudHJ5PgorICAg ICAgIDwvcm93PgorICAgICAgPC90aGVhZD4KKyAgICAgIDx0Ym9keT4KKyAg ICAgICA8cm93PgorICAgICAgICA8ZW50cnk+CisgICAgICAgICBSZWFkIGNv bW1pdHRlZAorICAgICAgICA8L2VudHJ5PgorICAgICAgICA8ZW50cnk+Cisg ICAgICAgICBOb3QgcG9zc2libGUKKyAgICAgICAgPC9lbnRyeT4KKyAgICAg ICAgPGVudHJ5PgorICAgICAgICAgUG9zc2libGUKKyAgICAgICAgPC9lbnRy eT4KKyAgICAgICAgPGVudHJ5PgorICAgICAgICAgUG9zc2libGUKKyAgICAg ICAgPC9lbnRyeT4KKyAgICAgICA8L3Jvdz4KKworICAgICAgIDxyb3c+Cisg ICAgICAgIDxlbnRyeT4KKyAgICAgICAgIFJlcGVhdGFibGUgcmVhZAorICAg ICAgICA8L2VudHJ5PgorICAgICAgICA8ZW50cnk+CisgICAgICAgICBOb3Qg cG9zc2libGUKKyAgICAgICAgPC9lbnRyeT4KKyAgICAgICAgPGVudHJ5Pgor ICAgICAgICAgTm90IHBvc3NpYmxlCisgICAgICAgIDwvZW50cnk+CisgICAg ICAgIDxlbnRyeT4KKyAgICAgICAgIE5vdCBQb3NzaWJsZQorICAgICAgICA8 L2VudHJ5PgorICAgICAgIDwvcm93PgorCisgICAgICAgPHJvdz4KKyAgICAg ICAgPGVudHJ5PgorICAgICAgICAgU2VyaWFsaXphYmxlCisgICAgICAgIDwv ZW50cnk+CisgICAgICAgIDxlbnRyeT4KKyAgICAgICAgIE5vdCBwb3NzaWJs ZQorICAgICAgICA8L2VudHJ5PgorICAgICAgICA8ZW50cnk+CisgICAgICAg ICBOb3QgcG9zc2libGUKKyAgICAgICAgPC9lbnRyeT4KKyAgICAgICAgPGVu dHJ5PgorICAgICAgICAgTm90IHBvc3NpYmxlCisgICAgICAgIDwvZW50cnk+ CisgICAgICAgPC9yb3c+CisgICAgICA8L3Rib2R5PgorICAgICA8L3Rncm91 cD4KKyAgICA8L3RhYmxlPgorCisgICA8cGFyYT4KKyAgICBBcyB0aGUgdGFi bGUgbWFrZXMgY2xlYXIgdGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBpbiB0aGUg cG90ZW50aWFsIHBoZW5vbWVuYQorICAgIGF0IHRoZSBSRVBFQVRBQkxFIFJF QUQgYW5kIFNFUklBTElaQUJMRSB0cmFuc2FjdGlvbiBpc29sYXRpb24gbGV2 ZWxzOyBidXQKKyAgICB0aGUgcGhlbm9tZW5hIGxpc3RlZCBvbmx5IHBlcnRh aW4gdG8gdGhlIGRhdGEgc2VlbiBieSB0aGUgdHJhbnNhY3Rpb24uCisgICAg VGhlIGRpZmZlcmVuY2UgaXMgdGhhdCBSRVBFQVRBQkxFIFJFQUQgd2lsbCBv bmx5IHNlcmlhbC1mYWlsCisgICAgaWYgdHdvIHRyYW5zYWN0aW9ucyBhdHRl bXB0IHRvIG1vZGlmeSB0aGUgc2FtZSByZWNvcmQgd2hpbGUgU0VSSUFMSVpB QkxFIHdpbGwgCisgICAgYWxzbyBzZXJpYWwtZmFpbCBpZiBvbmUgdHJhbnNh Y3Rpb24gbW9kaWZpZXMgYSByZWNvcmQgdGhhdCBhbm90aGVyIHRyYW5zYWN0 aW9uIAorICAgIGhhcyBvbmx5IHJlYWQuCisgICA8L3BhcmE+CisgICAKKyAg IDxwYXJhPgogICAgIFRvIHNldCB0aGUgdHJhbnNhY3Rpb24gaXNvbGF0aW9u IGxldmVsIG9mIGEgdHJhbnNhY3Rpb24sIHVzZSB0aGUKICAgICBjb21tYW5k IDx4cmVmIGxpbmtlbmQ9InNxbC1zZXQtdHJhbnNhY3Rpb24iPi4KICAgIDwv cGFyYT4K --089e0116197a5fb21c0513f40d10 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs --089e0116197a5fb21c0513f40d10-- From peter_e@gmx.net Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Ylgup-0008Qs-Q2 for pgsql-docs@arkaria.postgresql.org; Fri, 24 Apr 2015 16:57:23 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Ylgun-0004hG-QA for pgsql-docs@arkaria.postgresql.org; Fri, 24 Apr 2015 16:57:21 +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 1Ylgum-0004h9-Sy for pgsql-docs@postgresql.org; Fri, 24 Apr 2015 16:57:20 +0000 Received: from mout.gmx.net ([212.227.17.20]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Ylgue-0000o2-Tg for pgsql-docs@postgresql.org; Fri, 24 Apr 2015 16:57:19 +0000 Received: from auth1-smtp.messagingengine.com ([66.111.4.227]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Mb8HX-1Z0kvN23cR-00KdFv for ; Fri, 24 Apr 2015 18:57:10 +0200 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 24FF920EF4 for ; Fri, 24 Apr 2015 12:57:08 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 24 Apr 2015 12:57:08 -0400 X-Sasl-enc: krHat9dIeuhBB7cfz5ZJGT9KZRHIbsFMdudSIehikyZ5 1429894627 Received: from [192.168.1.117] (unknown [204.145.120.11]) by mail.messagingengine.com (Postfix) with ESMTPA id D76A7C00017; Fri, 24 Apr 2015 12:57:07 -0400 (EDT) Message-ID: <553A75E3.4080807@gmx.net> Date: Fri, 24 Apr 2015 12:57:07 -0400 From: Peter Eisentraut User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "David G. Johnston" , Bruce Momjian CC: "pgsql-docs@postgresql.org" Subject: Re: Add a new table for Transaction Isolation? References: <20150416012128.GB1672@momjian.us> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:CcSDnYi1YEQFxqO4lHDXsW0c6IESNhgFkMdDbVziHwujei7AxFV MWQ5JZGb7s/nOHYCjWWMdDFk3K1Bq7+juMVvBAVMActC1dhi8yzbQGAzYA3rRavvjjJIF9r 1Tv6iPFnTTBiNPXf3jcVUelf642PX+QQxeD3hi6Qr3sYqirzqS4khX7lDAlyTNL0LxidE7I ZG1aSw2+R8IDgU7zXh8ig== X-UI-Out-Filterresults: notjunk:1; X-Pg-Spam-Score: -2.1 (--) 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 4/17/15 7:36 PM, David G. Johnston wrote: > diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml > index f88b16e..5002138 100644 > --- a/doc/src/sgml/mvcc.sgml > +++ b/doc/src/sgml/mvcc.sgml > @@ -100,6 +100,14 @@ > phenomena caused by interactions?) > > > + > + The concepts covered in this section are > + presented without examples of the behaviors described. The internet, > + including and espcially the PostgreSQL Wiki, is > + an excellent resource to learn more about circumstances under which these > + data phenomena occur, and what the results look like when they do. > + > + I don't think our documentation should go out of its way to say, "our documentation is bad, look elsewhere". If we think examples are necessary, then we should add some. Otherwise, it's implied that improvement is always possible. > > The phenomena which are prohibited at various levels are: > > @@ -150,12 +158,12 @@ > > transaction isolation level > > - The four transaction isolation levels and the corresponding > - behaviors are described in . > + The four SQL transaction isolation levels, and their corresponding > + behaviors, are described in . > I don't think this change is good. > >
> - Standard <acronym>SQL</acronym> Transaction Isolation Levels > + <acronym>SQL</acronym> Standard Transaction Isolation Levels > > > Why this change? > @@ -256,6 +264,89 @@ > > > > + The three PostgreSQL transaction isolation levels, and their corresponding > + behaviors, are described in . > + This isn't really correct. The PostgreSQL isolation levels were described in the paragraph above. The table is really just a summary of the previous explanation. > + > + As the table makes clear there is no difference in the potential phenomena > + at the REPEATABLE READ and SERIALIZABLE transaction isolation levels; but > + the phenomena listed only pertain to the data seen by the transaction. Please adapt the existing spelling and capitalization. > + The difference is that REPEATABLE READ will only serial-fail This term "serial-fail" would need further explanation. > + if two transactions attempt to modify the same record while SERIALIZABLE will > + also serial-fail if one transaction modifies a record that another transaction > + has only read. > + I don't think this new table adds clarity. Users should generally have their applications use the appropriate standard isolation level. Adding another table that says, some of these are not actually different, following by text that says they are different in other ways, just repeats the point that was made earlier and will be explained in more detail in the following subsections. The real difference, in my mind, is that the SQL standard defines four levels in terms of three criteria, but PostgreSQL really has four criteria and only three different levels implemented. It might be worth visualizing that somehow. Note that when that section was initially written, the fourth criterion (serializability) wasn't implemented. -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs From david.g.johnston@gmail.com Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Ylhuw-0003D0-87 for pgsql-docs@arkaria.postgresql.org; Fri, 24 Apr 2015 18:01:34 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Ylhuv-0000Lb-46 for pgsql-docs@arkaria.postgresql.org; Fri, 24 Apr 2015 18:01:33 +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 1Ylhuu-0000LV-4x for pgsql-docs@postgresql.org; Fri, 24 Apr 2015 18:01:32 +0000 Received: from mail-ig0-x232.google.com ([2607:f8b0:4001:c05::232]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1Ylhun-00026C-Jz for pgsql-docs@postgresql.org; Fri, 24 Apr 2015 18:01:29 +0000 Received: by igblo3 with SMTP id lo3so20974823igb.1 for ; Fri, 24 Apr 2015 11:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hVsp6VRlORJLEvFdC0zqTCGiymOxvVo40v8jjJafvyE=; b=Jkjo3bXqwycpYqM38VWPOGltHFxI/6U1ngc0I7Aj0ecIU9IYXv+ztZQFj9sgcQ1bBG 756fvgRll8hzMKz7VTifGQcPDxBxNHsxoMhWPlsTyQ+aZ1ITSryIwr1pwhEfwtqOIBeo JJL0DA+MgTac22ICmlFVsKTGAzLsPZV4CZ8MJKWNxle2EeNk1nZAUVvx6/R6rr/zUX9G hLQ4IsRHuOX2ZLNHafEJY7I/tcbO6itYX7/KGxQb6M6gbbLgtebLs9iNga7LQD+MSw+B ssYtEqf2aGFgcC+TRYL047nCbxDAM22uPtSB1weYU9+VBarpmY8l5q/csLEFDzY9s6Xt KNNg== MIME-Version: 1.0 X-Received: by 10.43.178.201 with SMTP id ox9mr202573icc.49.1429898484228; Fri, 24 Apr 2015 11:01:24 -0700 (PDT) Received: by 10.36.64.15 with HTTP; Fri, 24 Apr 2015 11:01:24 -0700 (PDT) In-Reply-To: <553A75E3.4080807@gmx.net> References: <20150416012128.GB1672@momjian.us> <553A75E3.4080807@gmx.net> Date: Fri, 24 Apr 2015 11:01:24 -0700 Message-ID: Subject: Re: Add a new table for Transaction Isolation? From: "David G. Johnston" To: Peter Eisentraut Cc: Bruce Momjian , "pgsql-docs@postgresql.org" Content-Type: multipart/alternative; boundary=001a11c318de37a6d405147c2fb1 X-Pg-Spam-Score: -2.7 (--) 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 --001a11c318de37a6d405147c2fb1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 24, 2015 at 9:57 AM, Peter Eisentraut wrote: > On 4/17/15 7:36 PM, David G. Johnston wrote: > > diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml > > index f88b16e..5002138 100644 > > --- a/doc/src/sgml/mvcc.sgml > > +++ b/doc/src/sgml/mvcc.sgml > > @@ -100,6 +100,14 @@ > > phenomena caused by interactions?) > > > > > > + > > + The concepts covered in this section are > > + presented without examples of the behaviors described. The interne= t, > > + including and espcially the PostgreSQL > Wiki, is > > + an excellent resource to learn more about circumstances under which > these > > + data phenomena occur, and what the results look like when they do. > > + > > + > > I don't think our documentation should go out of its way to say, "our > documentation is bad, look elsewhere". If we think examples are > necessary, then we should add some. Otherwise, it's implied that > improvement is always possible. > =E2=80=8BI'm not - I am explicitly listing the assumptions the documentatio= n makes regarding reader experience (and ease of documenting) - and pointing out were the reader can go if their experience is lacking in those areas.=E2=80= =8B It seems unproductive to move all of the SSI content on our Wiki into the documentation and so, lacking such, we should point out where else content can be found. > > > > > The phenomena which are prohibited at various levels are: > > > > @@ -150,12 +158,12 @@ > > > > transaction isolation level > > > > - The four transaction isolation levels and the corresponding > > - behaviors are described in . > > + The four SQL transaction isolation levels, and their corresponding > > + behaviors, are described in = . > > > > I don't think this change is good. > I think it reads cleaner but not so much as to argue it. > > > > >
> > - Standard <acronym>SQL</acronym> Transaction Isolation > Levels > > + <acronym>SQL</acronym> Standard Transaction Isolation > Levels > > > > > > > > Why this change? > =E2=80=8BThe new table reads "PostgreSQL ..." and the corresponding noun is= the "SQL Standard". Writing "Standard SQL" can be read as implying the existence of "Non-Standard SQL..." which is not correct. Just saying "SQL..." seems to be too generic - though after reading the conclusion and pondering that "SQL Standard" could also imply "SQL Non-Standard..." I'm not so sure whether just saying SQL wouldn't be best. "Here are the four words that can be used with SET TRANSACTION ISOLATION LEVEL..." - and then show/describe the minimum required non-behaviors and the non-behaviors as implemented in PostgreSQL. =E2=80=8BMaybe possessive would work "PostgreSQL's ..." and "SQL Standard's= ..."=E2=80=8B > > @@ -256,6 +264,89 @@ > > > > > > > > + The three PostgreSQL transaction > isolation levels, and their corresponding > > + behaviors, are described in linkend=3D"mvcc-pgsql-isolevel-table">. > > + > > This isn't really correct. The PostgreSQL isolation levels were > described in the paragraph above. The table is really just a summary of > the previous explanation. > =E2=80=8B"[...], are summarized in " ? =E2=80=8B > > > + > > + As the table makes clear there is no difference in the potential > phenomena > > + at the REPEATABLE READ and SERIALIZABLE transaction isolation > levels; but > > + the phenomena listed only pertain to the data seen by the > transaction. > > Please adapt the existing spelling and capitalization. > =E2=80=8BOK =E2=80=8B > > > + The difference is that REPEATABLE READ will only serial-fail > > This term "serial-fail" would need further explanation. > =E2=80=8BI will probably stick with the more verbose "serialization failure= "...does that require explaining here, or a xref? =E2=80=8B > > > + if two transactions attempt to modify the same record while > SERIALIZABLE will > > + also serial-fail if one transaction modifies a record that another > transaction > > + has only read. > > + > > I don't think this new table adds clarity. Users should generally have > their applications use the appropriate standard isolation level. > =E2=80=8B > =E2=80=8B=E2=80=8BThen why not sure write the entire section relative to th= e standard and point out the differences between the standard and our implementation on the command definition page in the compatibility section? =E2=80=8Bhttp://www.postgresql.org/docs/devel/static/sql-set-transaction.ht= ml =E2=80=8B > Adding > another table that says, some of these are not actually different, > following by text that says they are different in other ways, just > repeats the point that was made earlier and will be explained in more > detail in the following subsections. > > The real difference, in my mind, is that the SQL standard defines four > levels in terms of three criteria, but PostgreSQL really has four > criteria and only three different levels implemented. It might be worth > visualizing that somehow. > =E2=80=8BWell, I would at least add "Read uncommitted" to the PostgreSQL ta= ble and have it setup the same as "Read committed". We do implement all four - by name. And, as to the prior point, visualizing the differences seems best accomplished in a compatibility section and likely will just confuse the issue here - if indeed the expectation is that users will define their requirements relative to the standard and not relative to our implementation. =E2=80=8BOtherwise, a summary table describing our implementation seems lik= e a self-evident need. We are already going to great lengths to describe everything in the table anyway and we already are using a table to describe the standard's definitions.=E2=80=8B Placing said table here seems easiest= and if summarizing what is already present in the text somehow makes the section more confusing I posit that it must already be confusing without the table. At least this way the confusing stuff is summarized and is readily available for lookup by those who know what they are looking for. =E2=80=8B For clarity - what is the 4th criteria that you are thinking of? More specifically, how would you name it so that it could be a table column? Two separate patches here: 1) =E2=80=8Bpointing out that additional information is available on the wi= ki and the internet 2) summarizing the PostgreSQL implementation into a table similar to that already present for the Standard #2 can be implemented in the MVCC section or a more extensive patch can also update the SQL command SET TRANSACTION section - which will mean someone feels strongly enough that the status quo is better than updating MVCC while waiting for someone to write the more invasive patch. =E2=80=8BDavid J.=E2=80=8B --001a11c318de37a6d405147c2fb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Ap= r 24, 2015 at 9:57 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 4/17/15 7:36 PM, David G. Johnston wro= te:
> diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
> index f88b16e..5002138 100644
> --- a/doc/src/sgml/mvcc.sgml
> +++ b/doc/src/sgml/mvcc.sgml
> @@ -100,6 +100,14 @@
>=C2=A0 =C2=A0 =C2=A0 phenomena caused by interactions?)
>=C2=A0 =C2=A0 =C2=A0</para>
>
> +=C2=A0 <para>
> +=C2=A0 =C2=A0The concepts covered in this section are
> +=C2=A0 =C2=A0presented without examples of the behaviors described.= =C2=A0 The internet,
> +=C2=A0 =C2=A0including and espcially the <productname>PostgreSQ= L</productname> Wiki, is
> +=C2=A0 =C2=A0an excellent resource to learn more about circumstances = under which these
> +=C2=A0 =C2=A0data phenomena occur, and what the results look like whe= n they do.
> +=C2=A0 </para>
> +

I don't think our documentation should go out of its way to say, "= our
documentation is bad, look elsewhere".=C2=A0 If we think examples are<= br> necessary, then we should add some.=C2=A0 Otherwise, it's implied that<= br> improvement is always possible.

=E2= =80=8BI'm not - I am explicitly listing the assumptions the documentati= on makes regarding reader experience (and ease of documenting) - and pointi= ng out were the reader can go if their experience is lacking in those areas= .=E2=80=8B =C2=A0It seems unproductive to move all of the SSI content on ou= r Wiki into the documentation and so, lacking such, we should point out whe= re else content can be found.
=C2=A0

>=C2=A0 =C2=A0 =C2=A0<para>
>=C2=A0 =C2=A0 =C2=A0 The phenomena which are prohibited at various leve= ls are:
>
> @@ -150,12 +158,12 @@
>=C2=A0 =C2=A0 =C2=A0 <indexterm>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<primary>transaction isolation level&l= t;/primary>
>=C2=A0 =C2=A0 =C2=A0 </indexterm>
> -=C2=A0 =C2=A0 The four transaction isolation levels and the correspon= ding
> -=C2=A0 =C2=A0 behaviors are described in <xref linkend=3D"mvc= c-isolevel-table">.
> +=C2=A0 =C2=A0 The four SQL transaction isolation levels, and their co= rresponding
> +=C2=A0 =C2=A0 behaviors, are described in <xref linkend=3D"mv= cc-isolevel-table">.
>=C2=A0 =C2=A0 =C2=A0</para>

I don't think this change is good.

=
I think it reads cleaner but not so much as to argue it.
=C2=A0

>
>=C2=A0 =C2=A0 =C2=A0 <table tocentry=3D"1" id=3D"mvcc= -isolevel-table">
> -=C2=A0 =C2=A0 =C2=A0<title>Standard <acronym>SQL</acro= nym> Transaction Isolation Levels</title>
> +=C2=A0 =C2=A0 =C2=A0<title><acronym>SQL</acronym> S= tandard Transaction Isolation Levels</title>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<tgroup cols=3D"4">
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <thead>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<row>

Why this change?

=E2=80=8BThe new ta= ble reads "PostgreSQL ..." and the corresponding noun is the &quo= t;SQL Standard".=C2=A0 Writing "Standard SQL" can be read as= implying the existence of "Non-Standard SQL..." which is not cor= rect.=C2=A0 Just saying "SQL..." seems to be too generic - though= after reading the conclusion and pondering that "SQL Standard" c= ould also imply "SQL Non-Standard..." I'm not so sure whether= just saying SQL wouldn't be best. =C2=A0"Here are the four words = that can be used with SET TRANSACTION ISOLATION LEVEL..." - and then s= how/describe the minimum required non-behaviors and the non-behaviors as im= plemented in PostgreSQL.

=E2=80=8BMaybe p= ossessive would work "PostgreSQL's ..." and "SQL Standar= d's..."=E2=80=8B


> @@ -256,6 +264,89 @@
>=C2=A0 =C2=A0 =C2=A0</para>
>
>=C2=A0 =C2=A0 =C2=A0<para>
> +=C2=A0 =C2=A0 The three <productname>PostgreSQL</productname= > transaction isolation levels, and their corresponding
> +=C2=A0 =C2=A0 behaviors, are described in <xref linkend=3D"mv= cc-pgsql-isolevel-table">.
> +=C2=A0 =C2=A0</para>

This isn't really correct.=C2=A0 The PostgreSQL isolation levels were described in the paragraph above.=C2=A0 The table is really just a summary = of
the previous explanation.

=E2=80=8B"[...], are summarized in <xref...>" ?
<= /div>
=E2=80=8B
=C2=A0

> +=C2=A0 =C2=A0<para>
> +=C2=A0 =C2=A0 As the table makes clear there is no difference in the = potential phenomena
> +=C2=A0 =C2=A0 at the REPEATABLE READ and SERIALIZABLE transaction iso= lation levels; but
> +=C2=A0 =C2=A0 the phenomena listed only pertain to the data seen by t= he transaction.

Please adapt the existing spelling and capitalization.

=E2=80=8BOK
=E2=80=8B
=C2=A0

> +=C2=A0 =C2=A0 The difference is that REPEATABLE READ will only serial= -fail

This term "serial-fail" would need further explanation.

=E2=80=8BI will probably stick= with the more verbose "serialization failure"...does that requir= e explaining here, or a xref?
=E2=80=8B=C2=A0

> +=C2=A0 =C2=A0 if two transactions attempt to modify the same record w= hile SERIALIZABLE will
> +=C2=A0 =C2=A0 also serial-fail if one transaction modifies a record t= hat another transaction
> +=C2=A0 =C2=A0 has only read.
> +=C2=A0 =C2=A0</para>

I don't think this new table adds clarity.=C2=A0 Users should generally= have
their applications use the appropriate standard isolation level.
=E2=80=8B

=E2=80=8B=E2=80= =8BThen why not sure write the entire section relative to the standard and = point out the differences between the standard and our implementation on th= e command definition page in the compatibility section?
Adding
another table that says, some of these are not actually different,
following by text that says they are different in other ways, just
repeats the point that was made earlier and will be explained in more
detail in the following subsections.

The real difference, in my mind, is that the SQL standard defines four
levels in terms of three criteria, but PostgreSQL really has four
criteria and only three different levels implemented.=C2=A0 It might be wor= th
visualizing that somehow.

=E2=80=8BW= ell, I would at least add "Read uncommitted" to the PostgreSQL ta= ble and have it setup the same as "Read committed".=C2=A0 We do i= mplement all four - by name.

And, as to the pri= or point, visualizing the differences seems best accomplished in a compatib= ility section and likely will just confuse the issue here - if indeed the e= xpectation is that users will define their requirements relative to the sta= ndard and not relative to our implementation.

= =E2=80=8BOtherwise, a summary table describing our implementation seems lik= e a self-evident need.=C2=A0 We are already going to great lengths to descr= ibe everything in the table anyway and we already are using a table to desc= ribe the standard's definitions.=E2=80=8B =C2=A0Placing said table here= seems easiest and if summarizing what is already present in the text someh= ow makes the section more confusing I posit that it must already be confusi= ng without the table.=C2=A0 At least this way the confusing stuff is summar= ized and is readily available for lookup by those who know what they are lo= oking for.
=E2=80=8B
For clarity - what is the 4= th criteria that you are thinking of?=C2=A0 More specifically, how would yo= u name it so that it could be a table column?

Two sep= arate patches here:

1) =E2=80=8Bpointing out that addi= tional information is available on the wiki and the internet

2) summarizing the PostgreSQL implementation into a table similar to= that already present for the Standard

#2 can be imple= mented in the MVCC section or a more extensive patch can also update the SQ= L command SET TRANSACTION section - which will mean someone feels strongly = enough that the status quo is better than updating MVCC while waiting for s= omeone to write the more invasive patch.

=E2=80=8BDavid J.=E2=80=8B


--001a11c318de37a6d405147c2fb1-- From kgrittn@ymail.com Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YlkP6-0002u7-K0 for pgsql-docs@arkaria.postgresql.org; Fri, 24 Apr 2015 20:40:53 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YlkP5-00005I-Va for pgsql-docs@arkaria.postgresql.org; Fri, 24 Apr 2015 20:40:52 +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 1YlkP4-00005B-Gn for pgsql-docs@postgresql.org; Fri, 24 Apr 2015 20:40:51 +0000 Received: from nm7-vm0.bullet.mail.ne1.yahoo.com ([98.138.91.66]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YlkOy-00056A-QO for pgsql-docs@postgresql.org; Fri, 24 Apr 2015 20:40:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ymail.com; s=s2048; t=1429908041; bh=4cXNIXHYnruj6M44LplSF+fWArkjeV22lsvH7UT5bO0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=c1vdcPJhwLhslPjUfn99NSSelLVMLfKJ1osz/BR1jEgJd6ewzwSSeUOBjbWrRbB6OPHdO2q4qE/GIRWBuC+9HNUyupMp73N7uFRtxLs3rdWGZp37u2SaIHWhQ28sWTXVjOAhlKT67t7d93PCW8U5v3VTNfTdeEOkv4M+RE0/PetNryuoTFZOHY55g439SdpwncWLX2ykTOQ+OIxM3A5LFHzWcirTNKRd0aP0T5OpLqdvdUWG2QUINymhxqxCGi4ThuqrtRH4SLDLaeI9IBDomF5nYFdbh0JWh50lzHSZ+BgAtUoR8MUp5Wo27UKidlilZqag0Esor85wgz25CL1sqA== Received: from [98.138.226.179] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 24 Apr 2015 20:40:41 -0000 Received: from [98.138.88.239] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 24 Apr 2015 20:40:41 -0000 Received: from [127.0.0.1] by omp1039.mail.ne1.yahoo.com with NNFMP; 24 Apr 2015 20:40:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 594075.95534.bm@omp1039.mail.ne1.yahoo.com X-YMail-OSG: 1XjGTDgVM1kVFnKXk08sydKY7JACDBLmTG6nivGDONR4jaVKMld6FiaVSXEiOb2 HtT78bIENvNZC6c6iwIoRMTeFKJx7xbjc436l6418BSs1B5yhppQbz1aTCEpYn_36l_HZYrnAfyJ paXozQWPhfAs41uJfGdk6TzjiGiQcCFOuribTjSEVZoq.Tvh0H5XnScpb4FA0IV.aYr5r37S4A4o mCVxxU_iBEzcqFU2.fDSdgPQ1UHob7qOlEnWavWoL4FwZMGx5emiwqP2pSNd1xAg1jGsTaMe2gGC 07inOxnpVUNTT5Tab.mdN82INAUD25Taa5447BmF1QKKqfG3nHvVD.t0ZMn1xZRxo7JZJ.h75PP0 1UyW5vqoz_hXEsKatWDecdtU.hikFm83kyENTLX6gOu9_Y2KxvjNR93RlXfeD96khZTguOs.o9dc WiHtlAxTUqSiy7htmasQ.QFQR2YDWEvUEhpbUXC4jFIHt8ZE4Ko2M8o7g3mJ3IshI5fmf1WPDBQS o11GjMcgKw8U5Jh4Mn5Oh Received: by 98.138.105.194; Fri, 24 Apr 2015 20:40:41 +0000 Date: Fri, 24 Apr 2015 20:40:40 +0000 (UTC) From: Kevin Grittner Reply-To: Kevin Grittner To: "David G. Johnston" , Peter Eisentraut Cc: Bruce Momjian , "pgsql-docs@postgresql.org" Message-ID: <1691752982.3879494.1429908040587.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: 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: 8970 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 David G. Johnston wrote: > On Fri, Apr 24, 2015 at 9:57 AM, Peter Eisentraut wrote: >> On 4/17/15 7:36 PM, David G. Johnston wrote: >>> + >>> + The concepts covered in this section are >>> + presented without examples of the behaviors described. The interne= t, >>> + including and espcially the PostgreSQL W= iki, is >>> + an excellent resource to learn more about circumstances under which= these >>> + data phenomena occur, and what the results look like when they do. >>> + >> >> I don't think our documentation should go out of its way to say, "our >> documentation is bad, look elsewhere". If we think examples are >> necessary, then we should add some. Otherwise, it's implied that >> improvement is always possible. > > =E2=80=8BI'm not - I am explicitly listing the assumptions the > documentation makes regarding reader experience (and ease of > documenting) - and pointing out were the reader can go if their > experience is lacking in those areas.=E2=80=8B It seems unproductive to > move all of the SSI content on our Wiki into the documentation and > so, lacking such, we should point out where else content can be > found. There have been suggestions before that some or all of the Wiki's SSI page be brought into the docs, or that the docs reference it. Bringing all of it in does seem like quite a lot for a single feature like this. I'm not sure what the best course is. >>>
>>> - Standard <acronym>SQL</acronym> Transaction Isolation Leve= ls >>> + <acronym>SQL</acronym> Standard Transaction Isolation Leve= ls >>> >>> >>> >> >> Why this change? > > =E2=80=8BThe new table reads "PostgreSQL ..." and the corresponding noun = is > the "SQL Standard". Writing "Standard SQL" can be read as implying > the existence of "Non-Standard SQL..." which is not correct. Just > saying "SQL..." seems to be too generic - though after reading the > conclusion and pondering that "SQL Standard" could also imply "SQL > Non-Standard..." I'm not so sure whether just saying SQL wouldn't > be best. "Here are the four words that can be used with SET > TRANSACTION ISOLATION LEVEL..." - and then show/describe the > minimum required non-behaviors and the non-behaviors as implemented > in PostgreSQL. > > =E2=80=8BMaybe possessive would work "PostgreSQL's ..." and "SQL Standard= 's..."=E2=80=8B Personally I think that "standard SQL" means "SQL, as defined by international standards documents." I see no benefit to changes along the lines suggested here. >>> >>> + The three PostgreSQL transaction isolat= ion levels, and their corresponding >>> + behaviors, are described in . >>> + >> >> This isn't really correct. The PostgreSQL isolation levels were >> described in the paragraph above. The table is really just a summary of >> the previous explanation. > > =E2=80=8B"[...], are summarized in " ? The problem with tables like this is that sometimes people just look at the table and assume that it is the *definition* of the isolation levels. At *no* point did *any* version of the SQL standard *ever* define the serializable transaction isolation level in terms of the phenomena shown in the table. The definition has always been: | The execution of concurrent SQL-transactions at isolation level | SERIALIZABLE is guaranteed to be serializable. A serializable | execution is defined to be an execution of the operations of | concurrently executing SQL-transactions that produces the same | effect as some serial execution of those same SQL-transactions. A | serial execution is one in which each SQL-transaction executes to | completion before the next SQL-transaction begins. Serializable transactions have been included in the table of which phenomena are allowed to occur at which isolation levels; but the table has always been followed by this note: | The exclusion of these phenomena for SQL-transactions executing | at isolation level SERIALIZABLE is a consequence of the | requirement that such transactions be serializable. Yet so many people have not looked beyond the table to see the actual definition of "serializable" in the standard that the absence of these three phenomena has often been mistakenly considered adequate for compliance with the standard. A 1995 paper titled "A Critique of ANSI SQL Isolation Levels" by Berenson, et al, notes this, saying: | Subclause 4.28, =E2=80=9CSQL-transactions=E2=80=9D, in [ANSI] notes that = the | SERIALIZABLE isolation level must provide what is =E2=80=9Ccommonly known | as fully serializable execution.=E2=80=9D The prominence of the table | compared to this extra proviso leads to a common misconception | that disallowing the three phenomena implies serializability. ... and later observes: | It would have been simpler [...] to drop [references to phantom | reads] and just use Subclause 4.28 to define ANSI SERIALIZABLE. I tend to agree. Not only would it have been simpler, I think it would have prevented a lot of misunderstanding of the requirements of the standard. Tables like this can do a lot more to promote confusion and misunderstanding than clarity. If we're going to make a change here, I think rather than doubling down on the standard's questionable inclusion of such a table by providing *two* tables, we should consider removing the existing table. > =E2=80=8B=E2=80=8BThen why not sure write the entire section relative to = the > standard and point out the differences between the standard and our > implementation on the command definition page in the compatibility > section? Many people don't have access to the standard, the standard is confusing to many, and the standard is specifically written to specify minimum required behaviors rather than anything that is dependent on implementation. The standard does not say that the READ UNCOMMITTED transaction isolation level allows other transactions to see the uncommitted work of a transaction; it merely says that no other transaction isolation level may do so. The same is true with all the phenomena -- our implementation does not "differ" from the standard on those points; it is in full compliance with it. > =E2=80=8BOtherwise, a summary table describing our implementation seems > like a self-evident need. We are already going to great lengths to > describe everything in the table anyway and we already are using a > table to describe the standard's definitions.=E2=80=8B Placing said table > here seems easiest and if summarizing what is already present in > the text somehow makes the section more confusing I posit that it > must already be confusing without the table. At least this way the > confusing stuff is summarized and is readily available for lookup > by those who know what they are looking for. But the table, by its nature, does not provide the full set of information, and too many people just look at the table because "it's easy". The question seems to me to be whether providing an easy way to get an inaccurate understanding of the topic has value; I submit that the confusion caused by the table in the standard (in spite of a note immediately after the table to try to prevent that) shows that it is not. > Two separate patches here: > > 1) =E2=80=8Bpointing out that additional information is available on the > wiki and the internet That and/or bringing in one or more of the Wiki example. > 2) summarizing the PostgreSQL implementation into a table similar > to that already present for the Standard > > #2 can be implemented in the MVCC section or a more extensive patch > can also update the SQL command SET TRANSACTION section - which > will mean someone feels strongly enough that the status quo is > better than updating MVCC while waiting for someone to write the > more invasive patch. 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. -- 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 From bruce@momjian.us Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Ym4Pr-0006le-4d for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 18:02:59 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Ym4Pp-0007iW-Na for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 18:02:57 +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 1Ym4Po-0007iQ-U7 for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 18:02:57 +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 1Ym4Pl-0003gA-Lh for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 18:02:55 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1Ym4Ph-0005wT-85; Sat, 25 Apr 2015 14:02:49 -0400 Date: Sat, 25 Apr 2015 14:02:49 -0400 From: Bruce Momjian To: Kevin Grittner Cc: "David G. Johnston" , Peter Eisentraut , "pgsql-docs@postgresql.org" Subject: Re: Add a new table for Transaction Isolation? Message-ID: <20150425180249.GA17791@momjian.us> References: <1691752982.3879494.1429908040587.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <1691752982.3879494.1429908040587.JavaMail.yahoo@mail.yahoo.com> 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 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + --uAKRQypu60I7Lcqm Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="isolation.diff" diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml new file mode 100644 index f88b16e..3120e1f *** a/doc/src/sgml/mvcc.sgml --- b/doc/src/sgml/mvcc.sgml *************** *** 150,162 **** transaction isolation level ! The four transaction isolation levels and the corresponding ! behaviors are described in .
! Standard <acronym>SQL</acronym> Transaction Isolation Levels ! --- 150,162 ---- transaction isolation level ! The SQL standard and PostgreSQL-implemented transaction isolation levels ! are described in .
! Transaction Isolation Levels ! *************** *** 171,182 **** Phantom Read ! Read uncommitted Possible --- 171,206 ---- Phantom Read + + Serialization Anomalies + ! Read uncommitted (SQL Standard) ! ! ! Possible ! ! ! Possible ! ! ! Possible ! ! ! Possible ! ! ! ! ! ! Read uncommitted (PostgreSQL) ! ! ! Not possible Possible *************** *** 202,212 **** Possible ! Repeatable read Not possible --- 226,260 ---- Possible + + Possible + ! Repeatable read (SQL Standard) ! ! ! Not possible ! ! ! Not possible ! ! ! Possible ! ! ! Possible ! ! ! ! ! ! Repeatable read (PostgreSQL) ! ! ! Not possible Not possible *************** *** 232,258 **** Not possible
! In PostgreSQL, you can request any of the ! four standard transaction isolation levels. But internally, there are ! only three distinct isolation levels, which correspond to the levels Read ! Committed, Repeatable Read, and Serializable. When you select the level Read ! Uncommitted you really get Read Committed, and phantom reads are not possible ! in the PostgreSQL implementation of Repeatable ! Read, so the actual ! isolation level might be stricter than what you select. This is ! permitted by the SQL standard: the four isolation levels only ! define which phenomena must not happen, they do not define which ! phenomena must happen. The reason that PostgreSQL ! only provides three isolation levels is that this is the only ! sensible way to map the standard isolation levels to the multiversion ! concurrency control architecture. The behavior of the available ! isolation levels is detailed in the following subsections. --- 280,309 ---- Not possible + + Not possible + ! In PostgreSQL, you can request any of ! the four standard transaction isolation levels, but internally only ! three distinct isolation levels are implemented, i.e. PostgreSQL's ! Read Uncommitted mode behaves like Read Committed. This is because ! it is the only sensible way to map the standard isolation levels to ! PostgreSQL's multiversion concurrency control architecture. ! ! ! ! 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. ! The behavior of the available isolation levels is detailed in the ! following subsections. --uAKRQypu60I7Lcqm Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs --uAKRQypu60I7Lcqm-- From david.g.johnston@gmail.com Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Ym4te-00081u-VJ for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 18:33:47 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Ym4te-0004ck-61 for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 18:33:46 +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 1Ym4td-0004ce-Bd for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 18:33:45 +0000 Received: from mail-ie0-x234.google.com ([2607:f8b0:4001:c03::234]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1Ym4tW-0004FM-EM for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 18:33:44 +0000 Received: by iedfl3 with SMTP id fl3so116812787ied.1 for ; Sat, 25 Apr 2015 11:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gnXa1uZF3mz/2pLwZ6+Dp92QdKr3BvTr9tewiB3y5s4=; b=IA7+MEp2YoTwF5nfNXVgnAchLyMtZh8uGv8MjOqXN2j2mIBZE8AvB1P97j+bHYasGa GOWQkz/qxMB0VO/bHnv93Z32CSUZaQEjtmIEdyr5XRZ7NbexhF91dxDjW7lAX4PFIU7j xrH9OrcoSder5CPYhuIM4nAySFUumDEPd64v0mAfi5xGdgS2Seyr/29LxQWXDjHNKe+V fESgoryah5LcK6RtYSCgMEAQWOBllh5SmT6Jy1pJq6HLNe3cRNFDaogBbo6JslNFxshk ByxjgX9duEaBAbrVyzwAT4qRDkulX9srg5M44BTQIIpSlBsPIihP8xAvHEoSbgs5+gpB YRFA== MIME-Version: 1.0 X-Received: by 10.107.165.206 with SMTP id o197mr5060809ioe.56.1429986816981; Sat, 25 Apr 2015 11:33:36 -0700 (PDT) Received: by 10.36.64.15 with HTTP; Sat, 25 Apr 2015 11:33:36 -0700 (PDT) In-Reply-To: <20150425180249.GA17791@momjian.us> References: <1691752982.3879494.1429908040587.JavaMail.yahoo@mail.yahoo.com> <20150425180249.GA17791@momjian.us> Date: Sat, 25 Apr 2015 11:33:36 -0700 Message-ID: Subject: Re: Add a new table for Transaction Isolation? From: "David G. Johnston" To: Bruce Momjian Cc: Kevin Grittner , Peter Eisentraut , "pgsql-docs@postgresql.org" Content-Type: multipart/alternative; boundary=001a11415074427f45051490c09e X-Pg-Spam-Score: -2.7 (--) 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 --001a11415074427f45051490c09e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. =E2=80=8BPondering whether something like: "Possible (not in PG)" and avoid= ing the additional rows would make reading the table easier. David J. --001a11415074427f45051490c09e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Ap= r 25, 2015 at 11:02 AM, Bruce Momjian <bruce@momjian.us> 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.=C2=A0 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<= br> > 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 tr= ouble
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.=C2=A0 You=
can see the output here, and the SGML patch is attached:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://momjian.us/expire/transaction-iso.html<= /a>

--001a11415074427f45051490c09e-- From bruce@momjian.us Sun May 24 04:56:30 2026 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 From kgrittn@ymail.com Sun May 24 04:56:30 2026 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 From bruce@momjian.us Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Ym6I6-0004eF-95 for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 20:03:06 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Ym6I5-0006Hx-P7 for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 20:03:05 +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 1Ym6I5-0006Hr-7n for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 20:03:05 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Ym6I0-0005EB-TK for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 20:03:04 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1Ym6Hv-0003JT-VA; Sat, 25 Apr 2015 16:02:55 -0400 Date: Sat, 25 Apr 2015 16:02:55 -0400 From: Bruce Momjian To: Kevin Grittner Cc: "David G. Johnston" , Peter Eisentraut , "pgsql-docs@postgresql.org" Subject: Re: Add a new table for Transaction Isolation? Message-ID: <20150425200255.GD17791@momjian.us> References: <20150425191617.GC17791@momjian.us> <112988831.4359293.1429991135817.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <112988831.4359293.1429991135817.JavaMail.yahoo@mail.yahoo.com> 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 07:45:35PM +0000, Kevin Grittner wrote: > 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. I don't think we can define the column as a negative, e.g. "Non-". > >> ​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. > > 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. Well, then "Possible" would refer to the SQL standard behavior, which seems kind of an odd thing to emphasize there. The field really needs to be "SQL-standard possible, PostgreSQL not possible", but that is too long. This is why I split it into separate lines. We could try "Possible (SQL standard), Not possible (PostgreSQL)". -- 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 From kgrittn@ymail.com Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Ym6zU-00072x-3X for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 20:47:56 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Ym6zT-0003aV-Jj for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 20:47:55 +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 1Ym6zS-0003aP-V5 for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 20:47:55 +0000 Received: from nm26-vm5.bullet.mail.ne1.yahoo.com ([98.138.91.248]) by makus.postgresql.org with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1Ym6zQ-0006kB-9G for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 20:47:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ymail.com; s=s2048; t=1429994869; bh=S3wQ/LofhrCRvnEisKX9r0QB4peMMtRUSpYQk4vleAs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Yh3yQID3UCLvOt7G6PD3g2/6/c3LNaLywT4u/ma9tBnDObhyDecRtgFI/i2HJkzJpgsPl+KE/sATZwvi1ZqSUOlAFxTTR3TITCIbXg4OjG/x8DI9+0X36xWSslNSk7T0tRI2pu+tKiWu1Jt4/mjcyGrDkuhyW7EoOFP0PDWxGReCOWUrBeH9tD6LA/1wBT73UkqyxoYZlRtDhFs/7E2wTrOLjOwbeTx8D5aG1TGYpefprPaxSDml5rZSb61Uki9EKRM7+8L7272XMT6D4+ojCJeuMRzEuBZuIZonwCB7R0uScM7tqnvBVzamrXSEk1V96hlNby57t3fNashgOq4t0g== Received: from [98.138.100.115] by nm26.bullet.mail.ne1.yahoo.com with NNFMP; 25 Apr 2015 20:47:49 -0000 Received: from [98.138.89.199] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 25 Apr 2015 20:47:49 -0000 Received: from [127.0.0.1] by omp1057.mail.ne1.yahoo.com with NNFMP; 25 Apr 2015 20:47:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 950390.33300.bm@omp1057.mail.ne1.yahoo.com X-YMail-OSG: B0Tc914VM1neB8z_ydsZXxPKqbWK0RH1Cv4D0GiR7EZYB39kC.2SSWOtvIM0iJb xX4b9gx1ZrYvyPqhsTc1yrkiao8Sce58mAgsJDY3BTjCsKoWp0v.vXNs4I55TbyYm.BkNzvh7olo A2JvAAkQOFUqZS45AosNNiNHaWZjXVhq5CtEpjT2P8okWJ.12cAPCpJJd0jnFCYqp0Nvfadc8nlq phQYaigL92prqgaxB0XPG09O3d_fcRrQm6vYeLUDUMzQkPSlsUT5XaYgpk_YyrZHV5QitE34jZgP E6KdQgDfYXK4_W3z8yE_81rmrOtFiqTPY5incsYs7SLdLjp0Nyjp3r6k1CsOT6Rgdbe36Y1U1U0n u0M5vGBptn7P7CEuVImKvxHKkjXZLDEWLGizfUmJdoCVukwJjBDez6VU8QL2haFMkx1fOgV_SM8T 7Ulb4paxve8g8HOp_tf0YcSfQXCn_Zi6A7hiImb5gpNGGwo6B5nZOojMlTOahkXILIbDt7zI9YvK 7UOAoTJzvXus1LD1lCyzL8VnQ4yTZOdpA3kZ0eeVqjPJSSX8XYLWnaA4CnA-- Received: by 98.138.105.200; Sat, 25 Apr 2015 20:47:49 +0000 Date: Sat, 25 Apr 2015 20:47:47 +0000 (UTC) From: Kevin Grittner Reply-To: Kevin Grittner To: Bruce Momjian Cc: "David G. Johnston" , Peter Eisentraut , "pgsql-docs@postgresql.org" Message-ID: <279680020.4245099.1429994867712.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150425200255.GD17791@momjian.us> References: <20150425200255.GD17791@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: 2606 X-Pg-Spam-Score: -2.2 (--) 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 07:45:35PM +0000, Kevin Grittner wrote: >> 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. > > I don't think we can define the column as a negative, e.g. > "Non-". Yeah, that would tend to add to confusion. The basic issue is whether there are any one-at-a-time orders of execution that could yield the same results, or whether there is a cycle in an attempt to graph such an order. "Cycles in Apparent Order of Execution" would be accurate, but it's kinda long, and possibly too arcane. >>>> =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. > > Well, then "Possible" would refer to the SQL standard behavior, > which seems kind of an odd thing to emphasize there. The field > really needs to be "SQL-standard possible, PostgreSQL not > possible", but that is too long. This is why I split it into > separate lines. We could try "Possible (SQL standard), Not > possible (PostgreSQL)". Yeah, I was searching for some wording that conveyed that the standard *allowed* an implementation to present such phenomena at the isolation level versus whether the PostgreSQL implementation could *actually* present such phenomena. In struggling to come up with an analogy, the best I can do is that it's like each person fishing for rainbow trout in Wisconsin is *allowed* to keep it if it is at least 26 inches long; some people will do so, and some catch and release. Regulations say that it is possible to keep it=20 (and not be in violation of the rules), but you are not required to=20 keep it. For REPEATABLE READ, the SQL standard says that any product would be *allowed* to have phantom reads, but is not *required* to; we, as a community, choose not to. Maybe something like "Prohibited", "Allowed but not Possible", and "Possible"? That would take a little explaining above, since our documentation's table would be deviating from the standard's table in its word choice. -- 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 From bruce@momjian.us Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Ym78V-0007W9-BN for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 20:57:15 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Ym78U-0004Aw-MX for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 20:57:14 +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 1Ym78T-0004Ap-RF for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 20:57:13 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Ym78L-0006DJ-Ig for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 20:57:12 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1Ym78G-0005St-Vx; Sat, 25 Apr 2015 16:57:00 -0400 Date: Sat, 25 Apr 2015 16:57:00 -0400 From: Bruce Momjian To: Kevin Grittner Cc: "David G. Johnston" , Peter Eisentraut , "pgsql-docs@postgresql.org" Subject: Re: Add a new table for Transaction Isolation? Message-ID: <20150425205700.GE17791@momjian.us> References: <20150425200255.GD17791@momjian.us> <279680020.4245099.1429994867712.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <279680020.4245099.1429994867712.JavaMail.yahoo@mail.yahoo.com> 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 08:47:47PM +0000, Kevin Grittner wrote: > Maybe something like "Prohibited", "Allowed but not Possible", and > "Possible"? That would take a little explaining above, since our > documentation's table would be deviating from the standard's table > in its word choice. I can't even process that. -- 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 From david.g.johnston@gmail.com Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Ym7Kf-0008AC-Vm for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 21:09:50 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Ym7Kf-0005Uf-Fh for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 21:09:49 +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 1Ym7Ke-0005UY-DQ for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 21:09:48 +0000 Received: from mail-ie0-x233.google.com ([2607:f8b0:4001:c03::233]) by magus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Ym7Ka-0006Pa-4b for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 21:09:47 +0000 Received: by iebrs15 with SMTP id rs15so104592738ieb.3 for ; Sat, 25 Apr 2015 14:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B82n1pkMTm35pNroXTpUQ41HqgsDZu4h4n94i5cNihk=; b=Ah6jsX/rdlhI+MzxKNdKMgl4WWfL4tBMiiNH5wyL9xbfyP9ir6mNCFqIREDzpW9v2m tjYBw70Jmol/PCe+NY/ltO511G4FDtAsjOd+LOC9mPYJXALA0c9XTeZTSQxp9r9x09jf tZSjARN8mo+hLu5zLaXBP9wgWMxD/zLqvaMT0T7uJ+e6fTaDwHYG4T+gZWt9gHlETIaW N9p4Hm46nJ5lfKn9yNXGkRrhtPC4XZ45Q3g6mC223pjzBxoNZriovKdjfKR0/z/1zxGy d0gioq+H0LviyPDCIAoSkBTQNRzrxnjTogH59c3vAGwm4sKd34rtENmceZub8tvwRTr1 xskw== MIME-Version: 1.0 X-Received: by 10.107.3.199 with SMTP id e68mr5330107ioi.92.1429996181851; Sat, 25 Apr 2015 14:09:41 -0700 (PDT) Received: by 10.36.64.15 with HTTP; Sat, 25 Apr 2015 14:09:41 -0700 (PDT) In-Reply-To: <279680020.4245099.1429994867712.JavaMail.yahoo@mail.yahoo.com> References: <20150425200255.GD17791@momjian.us> <279680020.4245099.1429994867712.JavaMail.yahoo@mail.yahoo.com> Date: Sat, 25 Apr 2015 14:09:41 -0700 Message-ID: Subject: Re: Add a new table for Transaction Isolation? From: "David G. Johnston" To: Kevin Grittner Cc: Bruce Momjian , Peter Eisentraut , "pgsql-docs@postgresql.org" Content-Type: multipart/alternative; boundary=001a113ed422731680051492ee15 X-Pg-Spam-Score: -2.7 (--) 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 --001a113ed422731680051492ee15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, April 25, 2015, Kevin Grittner wrote: > Bruce Momjian > wrote: > > On Sat, Apr 25, 2015 at 07:45:35PM +0000, Kevin Grittner wrote: > > >> 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. > > > > I don't think we can define the column as a negative, e.g. > > "Non-". > > Yeah, that would tend to add to confusion. The basic issue is > whether there are any one-at-a-time orders of execution that could > yield the same results, or whether there is a cycle in an attempt > to graph such an order. "Cycles in Apparent Order of Execution" > would be accurate, but it's kinda long, and possibly too arcane. "Monitored"? Are multiple transactions, that do not write to the same rows, monitored so that read dependencies between them are detected and a serialization error raised? > > >>>> =E2=80=8BPondering whether something like: "Possible (not in PG)" an= d > >>>> 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. > > > > Well, then "Possible" would refer to the SQL standard behavior, > > which seems kind of an odd thing to emphasize there. The field > > really needs to be "SQL-standard possible, PostgreSQL not > > possible", but that is too long. This is why I split it into > > separate lines. We could try "Possible (SQL standard), Not > > possible (PostgreSQL)". > > Yeah, I was searching for some wording that conveyed that the > standard *allowed* an implementation to present such phenomena at > the isolation level versus whether the PostgreSQL implementation > could *actually* present such phenomena. In struggling to come up > with an analogy, the best I can do is that it's like each person > fishing for rainbow trout in Wisconsin is *allowed* to keep it if > it is at least 26 inches long; some people will do so, and some > catch and release. Regulations say that it is possible to keep it > (and not be in violation of the rules), but you are not required to > keep it. For REPEATABLE READ, the SQL standard says that any > product would be *allowed* to have phantom reads, but is not > *required* to; we, as a community, choose not to. > > > Maybe something like "Prohibited", "Allowed but not Possible", and > "Possible"? That would take a little explaining above, since our > documentation's table would be deviating from the standard's table > in its word choice. > > Paraphrasing here... Table # presents the postgresql implementation of the sql standard isolation levels and notes the additional impermissible behaviors by including "(contra-SQL)" in the cell. "Contrary to the SQL standard" - the imprecision in the term seems acceptable. Not Possible (contra-SQL) --001a113ed422731680051492ee15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, April 25, 2015, Kevin Grittner <kgrittn@ymail.com> wrote:
bruce@momjian.us> wrote:
> On Sat, Apr 25, 2015 at 07:45:35PM +0000, Kevin Grittner wrote:

>> We could perhaps have the column header say "Non-Serializable=
>> Behavior" or some such; but I think we need to define whateve= r
>> term we use for the new column header.
>
> I don't think we can define the column as a negative, e.g.
> "Non-".

Yeah, that would tend to add to confusion.=C2=A0 The basic issue is
whether there are any one-at-a-time orders of execution that could
yield the same results, or whether there is a cycle in an attempt
to graph such an order.=C2=A0 "Cycles in Apparent Order of Execution&q= uot;
would be accurate, but it's kinda long, and possibly too arcane.

"Monitored"?

Are mu= ltiple transactions, that do not write to the same rows, monitored so that = read dependencies between them are detected and a serialization error raise= d?
=C2=A0

>>>> =E2=80=8BPondering whether something like: "Possible = (not in PG)" and
>>>> avoiding the additional rows would make reading the table<= br> >>>> easier.
>>>
>>> Uh, that's an idea.=C2=A0 I thought visually having two se= parate
>>> lines was cleaner.
>>
>> I think one row per transaction isolation level, with three
>> possible values per cell, would be the cleanest.=C2=A0 I have been=
>> trying to think of alternatives for the three values, but have
>> not come up with anything better than David's suggestion.
>
> Well, then "Possible" would refer to the SQL standard behavi= or,
> which seems kind of an odd thing to emphasize there.=C2=A0 The field > really needs to be "SQL-standard possible, PostgreSQL not
> possible", but that is too long.=C2=A0 This is why I split it int= o
> separate lines.=C2=A0 We could try "Possible (SQL standard), Not<= br> > possible (PostgreSQL)".

Yeah, I was searching for some wording that conveyed that the
standard *allowed* an implementation to present such phenomena at
the isolation level versus whether the PostgreSQL implementation
could *actually* present such phenomena.=C2=A0 In struggling to come up
with an analogy, the best I can do is that it's like each person
fishing for rainbow trout in Wisconsin is *allowed* to keep it if
it is at least 26 inches long; some people will do so, and some
catch and release.=C2=A0 Regulations say that it is possible to keep it
(and not be in violation of the rules), but you are not required to
keep it.=C2=A0 For REPEATABLE READ, the SQL standard says that any
product would be *allowed* to have phantom reads, but is not
*required* to; we, as a community, choose not to.


Maybe something like "Prohibited", "Allowed but not Possible= ", and
"Possible"?=C2=A0 That would take a little explaining above, sinc= e our
documentation's table would be deviating from the standard's table<= br> in its word choice.


Paraphrasing here...

<= div>Table # presents the postgresql implementation=C2=A0of the sql standard= isolation levels and notes the additional impermissible behaviors by inclu= ding "(contra-SQL)" in the cell. =C2=A0"Contrary to the=C2= =A0SQL standard" - the imprecision in the term seems=C2=A0acceptable.<= /div>

Not Possible (contra-SQL)
--001a113ed422731680051492ee15-- From david.g.johnston@gmail.com Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Ym7PP-0008Ng-2a for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 21:14:43 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Ym7PO-0005zW-Ht for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 21:14:42 +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 1Ym7PN-0005zP-Hj for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 21:14:41 +0000 Received: from mail-ig0-x22c.google.com ([2607:f8b0:4001:c05::22c]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1Ym7PK-0007Dv-Dt for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 21:14:40 +0000 Received: by iget9 with SMTP id t9so47667500ige.1 for ; Sat, 25 Apr 2015 14:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2O3TFSOi3IP5qXd0y67VJ4xozFQk9VVCLCLtpwymVyI=; b=iJJwzmBLG3md+VXK2r0LNpACjP15wM+phWlbCKOg364s3LUT2CPTT8d2RNy3XJMo1d JgpsknvM0gphCad5kKrZljwWWLQcZvq0iKPoWJEIm8h3FiGRY6kuDTPy2XXtRtU3uw6r uSrQPmcZkA0smhD715V12k2K+C4WBdGtxpEy7xxiuqM8gcGuBiOBlYqyyLPo1ulkNCFZ IQn9O6OVTTfj5gYoM0kBpMKMzmuqrP0R7GcG2ZzOedpU9OSbXPMtsv3WbRnf1xhEqOmX tq5SMivQ1P1ikveDiY4U0KudHtwdfMYPr0h36+CzAu2sktkC8oirN55NPnkBHOOuWZ7+ mt2w== MIME-Version: 1.0 X-Received: by 10.43.178.201 with SMTP id ox9mr5344438icc.49.1429996477459; Sat, 25 Apr 2015 14:14:37 -0700 (PDT) Received: by 10.36.64.15 with HTTP; Sat, 25 Apr 2015 14:14:37 -0700 (PDT) In-Reply-To: <20150425205700.GE17791@momjian.us> References: <20150425200255.GD17791@momjian.us> <279680020.4245099.1429994867712.JavaMail.yahoo@mail.yahoo.com> <20150425205700.GE17791@momjian.us> Date: Sat, 25 Apr 2015 14:14:37 -0700 Message-ID: Subject: Re: Add a new table for Transaction Isolation? From: "David G. Johnston" To: Bruce Momjian Cc: Kevin Grittner , Peter Eisentraut , "pgsql-docs@postgresql.org" Content-Type: multipart/alternative; boundary=001a11c318de11b3f70514930066 X-Pg-Spam-Score: -2.7 (--) 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 --001a11c318de11b3f70514930066 Content-Type: text/plain; charset=UTF-8 On Saturday, April 25, 2015, Bruce Momjian wrote: > On Sat, Apr 25, 2015 at 08:47:47PM +0000, Kevin Grittner wrote: > > Maybe something like "Prohibited", "Allowed but not Possible", and > > "Possible"? That would take a little explaining above, since our > > documentation's table would be deviating from the standard's table > > in its word choice. > > I can't even process that. > > After writing my thoughts this makes sense now. Prohibited means that both tables would say not possible. Possible means both tables would say possible. Allowed but not possible means our implementation says not possible and the standard says it is possible. The fourth possibility, not allowed but possible, would mean we are not standard conforming and since we are it never appears. I would probably choose "not possible (contra-SQL)" and emphasize our implementation and footnote the two differences. David J. --001a11c318de11b3f70514930066 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, April 25, 2015, Bruce Momjian <bruce@momjian.us> wrote:
O= n Sat, Apr 25, 2015 at 08:47:47PM +0000, Kevin Grittner wrote:
> Maybe something like "Prohibited", "Allowed but not Pos= sible", and
> "Possible"?=C2=A0 That would take a little explaining above,= since our
> documentation's table would be deviating from the standard's t= able
> in its word choice.

I can't even process that.


After writing my thoughts this makes sense= now.=C2=A0 Prohibited means that both tables would say not possible.=C2=A0= Possible means both tables would say possible.=C2=A0 Allowed but not possi= ble means our=C2=A0implementation says not possible and the standard says i= t is possible.=C2=A0 The fourth possibility, not allowed but possible, woul= d mean we are not standard conforming and since we are it never appears.

I would probably choose "not possible (contra-S= QL)" and emphasize our implementation and footnote the two differences= .

David J.
--001a11c318de11b3f70514930066-- From david.g.johnston@gmail.com Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Ym81V-0001bP-4t for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 21:54:05 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Ym81U-00009v-KL for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 21:54:04 +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 1Ym81T-00009p-SD for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 21:54:04 +0000 Received: from mail-ie0-x236.google.com ([2607:f8b0:4001:c03::236]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1Ym81R-0007xY-50 for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 21:54:02 +0000 Received: by iedfl3 with SMTP id fl3so118473602ied.1 for ; Sat, 25 Apr 2015 14:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g+XfxfBa0KYI5MZNCgPeViMCFPXCOCr7QPTs+NwRhNM=; b=G4VQDLhZ8tzO0d5LH6gDD+c221WTr4zL3ZKMfO/N15zZ6kYoFydshlccqh1sy96sDi m4S5FnOGGOo5FpkVuIZ8NfFqaY2flSYcX2TVPY8cnXNZU2NwZrA3Tc0biv5uTQr67Yw0 j1wfiFZWXhtg6fRwh1SPeNbViyZleAi2Rq/XoMRJm6YIDLOqf5TJA4FI/6Ixe0WyInzi iB2z7fFZUJ8NBpwOAO6twXpxA8yHZGNU70zFQOuC8Z/3e/KKQmxwSwhRqilWTU1eG3xA OYPlvV9PxLfbsu6aanG9IStFfSpw0ruGVDNf1COzwr4SE/ZFy4QHn571jM8oMiLMkY8u qjwA== MIME-Version: 1.0 X-Received: by 10.50.147.10 with SMTP id tg10mr5152889igb.36.1429998840122; Sat, 25 Apr 2015 14:54:00 -0700 (PDT) Received: by 10.36.64.15 with HTTP; Sat, 25 Apr 2015 14:54:00 -0700 (PDT) In-Reply-To: References: <20150425200255.GD17791@momjian.us> <279680020.4245099.1429994867712.JavaMail.yahoo@mail.yahoo.com> Date: Sat, 25 Apr 2015 14:54:00 -0700 Message-ID: Subject: Re: Add a new table for Transaction Isolation? From: "David G. Johnston" To: Kevin Grittner Cc: Bruce Momjian , Peter Eisentraut , "pgsql-docs@postgresql.org" Content-Type: multipart/alternative; boundary=089e0122a2d0e5168d0514938c25 X-Pg-Spam-Score: -1.7 (-) 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 --089e0122a2d0e5168d0514938c25 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, April 25, 2015, David G. Johnston wrote: > On Saturday, April 25, 2015, Kevin Grittner > wrote: > >> Bruce Momjian wrote: >> > On Sat, Apr 25, 2015 at 07:45:35PM +0000, Kevin Grittner wrote: >> >> >> 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. >> > >> > I don't think we can define the column as a negative, e.g. >> > "Non-". >> >> Yeah, that would tend to add to confusion. The basic issue is >> whether there are any one-at-a-time orders of execution that could >> yield the same results, or whether there is a cycle in an attempt >> to graph such an order. "Cycles in Apparent Order of Execution" >> would be accurate, but it's kinda long, and possibly too arcane. > > > "Monitored"? > > Are multiple transactions, that do not write to the same rows, monitored > so that read dependencies between them are detected and a serialization > error raised? > > >> >> >>>> =E2=80=8BPondering whether something like: "Possible (not in PG)" a= nd >> >>>> 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. >> > >> > Well, then "Possible" would refer to the SQL standard behavior, >> > which seems kind of an odd thing to emphasize there. The field >> > really needs to be "SQL-standard possible, PostgreSQL not >> > possible", but that is too long. This is why I split it into >> > separate lines. We could try "Possible (SQL standard), Not >> > possible (PostgreSQL)". >> >> Yeah, I was searching for some wording that conveyed that the >> standard *allowed* an implementation to present such phenomena at >> the isolation level versus whether the PostgreSQL implementation >> could *actually* present such phenomena. In struggling to come up >> with an analogy, the best I can do is that it's like each person >> fishing for rainbow trout in Wisconsin is *allowed* to keep it if >> it is at least 26 inches long; some people will do so, and some >> catch and release. Regulations say that it is possible to keep it >> (and not be in violation of the rules), but you are not required to >> keep it. For REPEATABLE READ, the SQL standard says that any >> product would be *allowed* to have phantom reads, but is not >> *required* to; we, as a community, choose not to. >> >> >> Maybe something like "Prohibited", "Allowed but not Possible", and >> "Possible"? That would take a little explaining above, since our >> documentation's table would be deviating from the standard's table >> in its word choice. >> >> > Paraphrasing here... > > Table # presents the postgresql implementation of the sql standard > isolation levels and notes the additional impermissible behaviors by > including "(contra-SQL)" in the cell. "Contrary to the SQL standard" - t= he > imprecision in the term seems acceptable. > > Not Possible (contra-SQL) > I'd also consider a 5th column to denote whether a serialization failure is possible in the first place and then the monitor column would distinguish between repeatable read and serializable. David J. --089e0122a2d0e5168d0514938c25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, April 25, 2015, David G. Johnston <david.g.johnston@gmail.com> wrote:
On Saturday, April 25, 2015, Kevin Grittner <kgrittn@ymail.com> wrote:
Bruce Momjian <bruce@momjian.us> wrote:
> On Sat, Apr 25, 2015 at 07:45:35PM +0000, Kevin Grittner wrote:

>> We could perhaps have the column header say "Non-Serializable=
>> Behavior" or some such; but I think we need to define whateve= r
>> term we use for the new column header.
>
> I don't think we can define the column as a negative, e.g.
> "Non-".

Yeah, that would tend to add to confusion.=C2=A0 The basic issue is
whether there are any one-at-a-time orders of execution that could
yield the same results, or whether there is a cycle in an attempt
to graph such an order.=C2=A0 "Cycles in Apparent Order of Execution&q= uot;
would be accurate, but it's kinda long, and possibly too arcane.

"Monitored"?

Are mu= ltiple transactions, that do not write to the same rows, monitored so that = read dependencies between them are detected and a serialization error raise= d?
=C2=A0

>>>> =E2=80=8BPondering whether something like: "Possible = (not in PG)" and
>>>> avoiding the additional rows would make reading the table<= br> >>>> easier.
>>>
>>> Uh, that's an idea.=C2=A0 I thought visually having two se= parate
>>> lines was cleaner.
>>
>> I think one row per transaction isolation level, with three
>> possible values per cell, would be the cleanest.=C2=A0 I have been=
>> trying to think of alternatives for the three values, but have
>> not come up with anything better than David's suggestion.
>
> Well, then "Possible" would refer to the SQL standard behavi= or,
> which seems kind of an odd thing to emphasize there.=C2=A0 The field > really needs to be "SQL-standard possible, PostgreSQL not
> possible", but that is too long.=C2=A0 This is why I split it int= o
> separate lines.=C2=A0 We could try "Possible (SQL standard), Not<= br> > possible (PostgreSQL)".

Yeah, I was searching for some wording that conveyed that the
standard *allowed* an implementation to present such phenomena at
the isolation level versus whether the PostgreSQL implementation
could *actually* present such phenomena.=C2=A0 In struggling to come up
with an analogy, the best I can do is that it's like each person
fishing for rainbow trout in Wisconsin is *allowed* to keep it if
it is at least 26 inches long; some people will do so, and some
catch and release.=C2=A0 Regulations say that it is possible to keep it
(and not be in violation of the rules), but you are not required to
keep it.=C2=A0 For REPEATABLE READ, the SQL standard says that any
product would be *allowed* to have phantom reads, but is not
*required* to; we, as a community, choose not to.


Maybe something like "Prohibited", "Allowed but not Possible= ", and
"Possible"?=C2=A0 That would take a little explaining above, sinc= e our
documentation's table would be deviating from the standard's table<= br> in its word choice.


Paraphrasing here...

<= div>Table # presents the postgresql implementation=C2=A0of the sql standard= isolation levels and notes the additional impermissible behaviors by inclu= ding "(contra-SQL)" in the cell. =C2=A0"Contrary to the=C2= =A0SQL standard" - the imprecision in the term seems=C2=A0acceptable.<= /div>

Not Possible (contra-SQL)
<= br>
=C2=A0 I'd=C2=A0also consider a 5th column to denote whether a= serialization failure is possible in the first place and then the monitor = column would distinguish between repeatable read and serializable.

David J.
--089e0122a2d0e5168d0514938c25-- From bruce@momjian.us Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YnDwO-0007Xf-IY for pgsql-docs@arkaria.postgresql.org; Tue, 28 Apr 2015 22:25:20 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YnDwO-0004fV-1e for pgsql-docs@arkaria.postgresql.org; Tue, 28 Apr 2015 22:25:20 +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 1YnDwM-0004ez-TD for pgsql-docs@postgresql.org; Tue, 28 Apr 2015 22:25:19 +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 1YnDwJ-0004uM-G5 for pgsql-docs@postgresql.org; Tue, 28 Apr 2015 22:25:17 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1YnDwG-0003Bl-1a; Tue, 28 Apr 2015 18:25:12 -0400 Date: Tue, 28 Apr 2015 18:25:12 -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: <20150428222512.GC31727@momjian.us> References: <20150425200255.GD17791@momjian.us> <279680020.4245099.1429994867712.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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 02:54:00PM -0700, David G. Johnston wrote: > Paraphrasing here... > > Table # presents the postgresql implementation of the sql standard > isolation levels and notes the additional impermissible behaviors by > including "(contra-SQL)" in the cell.  "Contrary to the SQL standard" - the > imprecision in the term seems acceptable. > > Not Possible (contra-SQL) > > >   I'd also consider a 5th column to denote whether a serialization failure is > possible in the first place and then the monitor column would distinguish > between repeatable read and serializable. I think the showing a serialization failure column is too much to add to the table. -- 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 From bruce@momjian.us Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YnDxC-0007Yh-AK for pgsql-docs@arkaria.postgresql.org; Tue, 28 Apr 2015 22:26:10 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YnDxB-00054u-RB for pgsql-docs@arkaria.postgresql.org; Tue, 28 Apr 2015 22:26:09 +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 1YnDxB-00054n-7V for pgsql-docs@postgresql.org; Tue, 28 Apr 2015 22:26:09 +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 1YnDx8-0004yK-Nr for pgsql-docs@postgresql.org; Tue, 28 Apr 2015 22:26:07 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1YnDx5-0003D4-Pr; Tue, 28 Apr 2015 18:26:03 -0400 Date: Tue, 28 Apr 2015 18:26:03 -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: <20150428222603.GD31727@momjian.us> References: <20150425200255.GD17791@momjian.us> <279680020.4245099.1429994867712.JavaMail.yahoo@mail.yahoo.com> <20150425205700.GE17791@momjian.us> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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 02:14:37PM -0700, David G. Johnston wrote: > On Saturday, April 25, 2015, Bruce Momjian wrote: > > On Sat, Apr 25, 2015 at 08:47:47PM +0000, Kevin Grittner wrote: > > Maybe something like "Prohibited", "Allowed but not Possible", and > > "Possible"?  That would take a little explaining above, since our > > documentation's table would be deviating from the standard's table > > in its word choice. > > I can't even process that. > > > > After writing my thoughts this makes sense now.  Prohibited means that both > tables would say not possible.  Possible means both tables would say possible.  > Allowed but not possible means our implementation says not possible and the > standard says it is possible.  The fourth possibility, not allowed but > possible, would mean we are not standard conforming and since we are it never > appears. > > I would probably choose "not possible (contra-SQL)" and emphasize our > implementation and footnote the two differences. I went with "Allowed, but not in PG" for those two fields, and removed the extra rows I had added. You can see the output here: http://momjian.us/expire/transaction-iso.html -- 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 From kgrittn@ymail.com Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YnSlz-0001ik-Du for pgsql-docs@arkaria.postgresql.org; Wed, 29 Apr 2015 14:15:35 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YnSly-0001VB-Mg for pgsql-docs@arkaria.postgresql.org; Wed, 29 Apr 2015 14:15:34 +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 1YnSlx-0001V2-HL for pgsql-docs@postgresql.org; Wed, 29 Apr 2015 14:15:33 +0000 Received: from nm27.bullet.mail.ne1.yahoo.com ([98.138.90.90]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YnSlp-0003dw-8a for pgsql-docs@postgresql.org; Wed, 29 Apr 2015 14:15:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ymail.com; s=s2048; t=1430316922; bh=SgbqzJ7sfc8jOVIu9axK5aPL5yYKd01Lh+2N3hZyff0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=YuvHrf15CC37wiz8fsR6ttade1Ss6OFTCxuA9gjxNr2/Fm70gMez7Lp0AWJjCpzrBVHhOFiQ5lDDcw9kQkM1ZBK6DM+dPTX+vsFLvM5VIy82SQ0RqjnaKFUDe2OU7GfrF+W+pC/2XSsO/OD7J6juLN7LDicSH4H08V9DD8ZZ6Qb3Jojf7/1qXRjvbwHoysU39gG9o7Y0awoR/s2r3EyBL1//jutPEk3yInHgRK9FmRBtTjDVH5u8ASsPxZgPdbdV/q/V38W954uuzEbNEqTCWnA2Lu/4IWr7pKaJZDRaRmyDMxKT++qr5ZwNIb4AOZcsaPQD3XhvBRcXqaKtwiEuAw== Received: from [98.138.101.131] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 29 Apr 2015 14:15:22 -0000 Received: from [98.138.89.232] by tm19.bullet.mail.ne1.yahoo.com with NNFMP; 29 Apr 2015 14:15:22 -0000 Received: from [127.0.0.1] by omp1047.mail.ne1.yahoo.com with NNFMP; 29 Apr 2015 14:15:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 82587.19062.bm@omp1047.mail.ne1.yahoo.com X-YMail-OSG: LEyVfQ8VM1nIVbkqwitf166CKubccEIpfuTT0JvXO_kQu0FKiLQzFx58voLwp0Z s74d_LlqV1OyOyNkCF.wuCaH9UTErVVX_CCzeub9RWSU9nERx3HDiBdPRNPjKs9LfPWVrroo2jsz xYnL6aZoJPAPi18QP5AjezmCvmKby22OACzZSH82ZF4fIenATxQsyMdQNPOujEURYm0mxdQO189q wMzk8vtytSJQ5TjK1T6klvIlE3h8nfa3e3ZepQEJLYST9UE1UtjDkiwJ6gP9_e41AnOtCua1SVME iUJWVr0oK2yOsIrBpAUhCB4YoviOmy67L.kwbMVjf8HCr5.95DjG9pvNK26XYvaGQk0YyQIuqd71 .K2aFX4Qptw571nfPlWSjTkIscrfhySNnbKol4v_1KeztL0GqSzii9kmZfb_tQpNkqDB1Zwr7aVn XXDCN9IfdKidcp.5nPwlHEKnWAmGJvOPYrMAIT3jfVs6TQ5stE8NkFrN7WODq.9o6.C9E_Je7Y4J dyCNPLhJfz1LLgaKYQnTTcr7vtnB5t7aW8gJrCYdK54jAQ158rOqdRZLUqA-- Received: by 98.138.105.201; Wed, 29 Apr 2015 14:15:21 +0000 Date: Wed, 29 Apr 2015 14:15:20 +0000 (UTC) From: Kevin Grittner Reply-To: Kevin Grittner To: Bruce Momjian , "David G. Johnston" Cc: Peter Eisentraut , "pgsql-docs@postgresql.org" Message-ID: <1416656552.447025.1430316920874.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150428222603.GD31727@momjian.us> References: <20150428222603.GD31727@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: 7bit Content-Length: 744 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: > I went with "Allowed, but not in PG" for those two fields, and > removed the extra rows I had added. You can see the output here: > > http://momjian.us/expire/transaction-iso.html Looks great! The only suggestion I can think to make to the table itself is to make the new column header singular, to match the other columns. I do think we should define the term used in the new column header; maybe something like this: serialization anomaly The result of successfully committing a group of transactions is inconsistent with all possible orderings of running those transactions one at a time. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs From bruce@momjian.us Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YnYHS-0003t8-4l for pgsql-docs@arkaria.postgresql.org; Wed, 29 Apr 2015 20:08:26 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YnYHR-0000RC-5z for pgsql-docs@arkaria.postgresql.org; Wed, 29 Apr 2015 20:08:25 +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 1YnYHQ-0000Pf-2Q for pgsql-docs@postgresql.org; Wed, 29 Apr 2015 20:08:24 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YnYHM-00020V-8l for pgsql-docs@postgresql.org; Wed, 29 Apr 2015 20:08:23 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1YnYHH-0004Pp-Ps; Wed, 29 Apr 2015 16:08:15 -0400 Date: Wed, 29 Apr 2015 16:08:15 -0400 From: Bruce Momjian To: Kevin Grittner Cc: "David G. Johnston" , Peter Eisentraut , "pgsql-docs@postgresql.org" Subject: Re: Add a new table for Transaction Isolation? Message-ID: <20150429200815.GL31727@momjian.us> References: <20150428222603.GD31727@momjian.us> <1416656552.447025.1430316920874.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1416656552.447025.1430316920874.JavaMail.yahoo@mail.yahoo.com> 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 Wed, Apr 29, 2015 at 02:15:20PM +0000, Kevin Grittner wrote: > Bruce Momjian wrote: > > > I went with "Allowed, but not in PG" for those two fields, and > > removed the extra rows I had added. You can see the output here: > > > > http://momjian.us/expire/transaction-iso.html > > > Looks great! > > The only suggestion I can think to make to the table itself is to > make the new column header singular, to match the other columns. > I do think we should define the term used in the new column header; > maybe something like this: > > > serialization anomaly > > The result of successfully committing a group of transactions > is inconsistent with all possible orderings of running those > transactions one at a time. OK, output updated: http://momjian.us/expire/transaction-iso.html -- 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 From kgrittn@ymail.com Sun May 24 04:56:30 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YnYM9-00045i-8U for pgsql-docs@arkaria.postgresql.org; Wed, 29 Apr 2015 20:13:17 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YnYM8-0002ll-KK for pgsql-docs@arkaria.postgresql.org; Wed, 29 Apr 2015 20:13:16 +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 1YnYM6-0002hR-4Q for pgsql-docs@postgresql.org; Wed, 29 Apr 2015 20:13:14 +0000 Received: from nm28-vm0.bullet.mail.ne1.yahoo.com ([98.138.91.22]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YnYM1-00026e-OP for pgsql-docs@postgresql.org; Wed, 29 Apr 2015 20:13:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ymail.com; s=s2048; t=1430338387; bh=h2kVlGK6a8hupLVYG67WAvIGjHb2WV+VuiBw4a+QIpw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=VkhD+qlsRCKwkTK1K7QsdDQ0erzmJ2YMhYd247VWlaRn0srxOa//6XYvEN5bhUtpKlhPhewsepfVTVgXQufAsNfnY8FwdWZgZQO7S2qLfwvlYarPheu3fXdSV+Jr2JO/ILdXuQOVWlQbO/VIgpBWB8axYMhKFg8Z3QFcvJnHPHNnB80fVLVkyNYG58MUlabyRZ0yRx52eVo94+9uECSO3ilzgyQXlZFhYxdU7cvIv3kEIgUEAw0wcXtpy+bOZ4XF5Npk/nneSFoyf7cUss9r+5444bCpDO6O+G+GW09if794BZnNJ5vMVN0KeU+wzkYVV2vlgCERIdwcpgASIm4soQ== Received: from [98.138.101.132] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 29 Apr 2015 20:13:07 -0000 Received: from [98.138.89.244] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 29 Apr 2015 20:13:07 -0000 Received: from [127.0.0.1] by omp1058.mail.ne1.yahoo.com with NNFMP; 29 Apr 2015 20:13:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 28634.93824.bm@omp1058.mail.ne1.yahoo.com X-YMail-OSG: GHpvTi0VM1nnZSRKRw36t2zpneWwQXbyGIPPgBdHUeuwkRPLQfMaBXZdQccMm4v uvR6yD5EBOwf6dw7JMyy9W8S0wy4eIVhGwqQzt10ZPAyhyzPF8If20sjXR9TDJeFWGRopGca5RDc ItcqxVtos4u9AECHqUTiWWfRdp7L3G7d3_PyUPKaNyw1FgPe4t4DXLuqwsoGhj7XK23wzdeOvFxS H1LopC2y79cZp50kJad6WWT4WZHZ4Z1us0Q87eV8Mw79koJAKlAvmZsFa8ZvOrd4IvkeRHOdGZkr UJIgR_xcNP03xlegaqZX_zVbXHGKD2jfaX_bxd.kSNhL3wtNUnXRhJI.IzHf6FgGNr3RTTBNk6_6 YKoJW1QXTELPeu0jYFnTyvtifmqVGN6ASJZffjBxqmsaUMDoj2u.kP6zCAuQh4mcc44pk38yFwk3 ma7Sndabgwd.wJe8xaEWu9AOn_OP51PFwKhF.E2P9XccSFEdgisCBmz.X85wamyh.segXs0RZr_T ogxA.fuMTk9DTsXsSCTa4Tg-- Received: by 98.138.105.253; Wed, 29 Apr 2015 20:13:06 +0000 Date: Wed, 29 Apr 2015 20:13:05 +0000 (UTC) From: Kevin Grittner Reply-To: Kevin Grittner To: Bruce Momjian Cc: "David G. Johnston" , Peter Eisentraut , "pgsql-docs@postgresql.org" Message-ID: <2098409833.744203.1430338385967.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150429200815.GL31727@momjian.us> References: <20150429200815.GL31727@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: 7bit Content-Length: 240 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: > updated: > > http://momjian.us/expire/transaction-iso.html I can't think of any way to improve on that. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs From bruce@momjian.us Sun May 24 04:56:31 2026 Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YrqCr-0000Pb-LY for pgsql-docs@arkaria.postgresql.org; Mon, 11 May 2015 16:05:25 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YrqCr-000736-58 for pgsql-docs@arkaria.postgresql.org; Mon, 11 May 2015 16:05:25 +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 1YrqCq-00072z-6X for pgsql-docs@postgresql.org; Mon, 11 May 2015 16:05:24 +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 1YrqCn-0004dd-GO for pgsql-docs@postgresql.org; Mon, 11 May 2015 16:05:22 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1YrqCk-0002Iv-Vv; Mon, 11 May 2015 12:05:18 -0400 Date: Mon, 11 May 2015 12:05:18 -0400 From: Bruce Momjian To: Kevin Grittner Cc: "David G. Johnston" , Peter Eisentraut , "pgsql-docs@postgresql.org" Subject: Re: Add a new table for Transaction Isolation? Message-ID: <20150511160518.GA8721@momjian.us> References: <20150428222603.GD31727@momjian.us> <1416656552.447025.1430316920874.JavaMail.yahoo@mail.yahoo.com> <20150429200815.GL31727@momjian.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150429200815.GL31727@momjian.us> 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 Wed, Apr 29, 2015 at 04:08:15PM -0400, Bruce Momjian wrote: > On Wed, Apr 29, 2015 at 02:15:20PM +0000, Kevin Grittner wrote: > > Bruce Momjian wrote: > > > > > I went with "Allowed, but not in PG" for those two fields, and > > > removed the extra rows I had added. You can see the output here: > > > > > > http://momjian.us/expire/transaction-iso.html > > > > > > Looks great! > > > > The only suggestion I can think to make to the table itself is to > > make the new column header singular, to match the other columns. > > I do think we should define the term used in the new column header; > > maybe something like this: > > > > > > serialization anomaly > > > > The result of successfully committing a group of transactions > > is inconsistent with all possible orderings of running those > > transactions one at a time. > > OK, output updated: > > http://momjian.us/expire/transaction-iso.html Patch applied. -- 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