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 <br...@momjian.us> 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?"
