Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t6yPu-00Gkz9-W3 for pgsql-docs@arkaria.postgresql.org; Fri, 01 Nov 2024 20:38:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t6yPt-00HPXc-5X for pgsql-docs@arkaria.postgresql.org; Fri, 01 Nov 2024 20:38:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t6yPs-00HPXU-UC for pgsql-docs@lists.postgresql.org; Fri, 01 Nov 2024 20:38:45 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t6yPq-004FJT-MM for pgsql-docs@lists.postgresql.org; Fri, 01 Nov 2024 20:38:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us; s=2024011501; h=In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-ID:Content-Description; bh=UR0I6EoFwCZomAXFvnlAXYUPBoLdJcS8NEZ8pWdh04I=; b=DC3vPbvtZPl4SKSq+8EiT6YRl9 EjGt2y7PdAI2z94KzPUZqfuhd/+aI03iTE9WDEHa7znoMdj4AQSIYwzI8Ag9JF0NpMkIR7M4VFkKC RJcEtAzD7QYvYk/0wg3BukCkk5b5J6lX6xAXAG0TWx6Cwouk82FrcrMKAY5UNLWkSLpFiCOWZ77Fp wmhoXcz93HLBa2TsxaX8WHY4PAtxnGYe/tmiHO5mc5HcHUAg0VHCSnzfNVoxZUurQowOYVZfgcsJM Zbquax96bXg1WJ/wJLg2tTAAqq9XwIH5OvMRsyijot4YaNfwV0/CEz5tNV56rNaFnTSvNCYWTOFLe zb0EH44g==; Received: from bruce by momjian.us with local (Exim 4.96) (envelope-from ) id 1t6yPn-009ocT-24; Fri, 01 Nov 2024 16:38:39 -0400 Date: Fri, 1 Nov 2024 16:38:39 -0400 From: Bruce Momjian To: "David G. Johnston" Cc: Tom Lane , marlene.brandstaetter@cargonet.software, pgsql-docs@lists.postgresql.org Subject: Re: Mistake in statement example Message-ID: References: <167765529052.987840.12345375075704447735@wrigleys.postgresql.org> <1522262.1677688451@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Sep 27, 2023 at 07:23:09PM -0400, Bruce Momjian wrote: > On Wed, Mar 1, 2023 at 09:45:00AM -0700, David G. Johnston wrote: > > That may be, but the descriptive text and point of the example (which isn't > > atomicity, but concurrency) doesn't even require the second update command to > > be present.  What the example could use is a more traditional two-session > > depiction of the commands instead of having a single transaction and letting > > the user envision the correct concurrency. > > > > Something like: > > > > S1: SELECT balance FROM accounts WHERE acctnum = 12345; //100 > > S1: BEGIN; > > S2: BEGIN; > > S1: UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 12345; //200 > > S2: UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 12345; // > > WAITING ON S1 > > S1: COMMIT; > > S2: UPDATED; balance = 300 > > S2: COMMIT; > > > > Though maybe "balance" isn't a good example domain, the incrementing example > > used just after this one seems more appropriate along with the added benefit of > > consistency. > > I developed the attached patch. I explained the example, I mentioned a > "second" transaciton, I changed the account number so I can talk about > the second statement, because read committed changes the row visibility > of the non-first statements, and I changed "transaction" to "statement". Patch from September 2023 applied. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com When a patient asks the doctor, "Am I going to die?", he means "Am I going to die soon?"