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 <bruce@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?"
