Re: [PATCH] Attempt to clarify example of serialization anomaly - Mailing list pgsql-docs

From Laurenz Albe
Subject Re: [PATCH] Attempt to clarify example of serialization anomaly
Date
Msg-id 2ede679a79a55f62450bcc7bc7893730c3a2e5ed.camel@cybertec.at
Whole thread Raw
In response to Re: [PATCH] Attempt to clarify example of serialization anomaly  (Will Mortensen <will@extrahop.com>)
List pgsql-docs
On Tue, 2023-06-20 at 20:01 -0700, Will Mortensen wrote:
> Rebased on master and updated the wording in several places. All
> feedback is appreciated. :-)
>
> I now see how to link to the wiki from the docs. I guess I numbered
> the transactions differently than the wiki's version though; I can
> rework it to more closely match the wiki if linking seems
> desirable.

I agree that the current wording in the documentation is too terse,
so your patch is an improvement.

There is still the potential for confusion.  Perhaps an example with
explicit SQL statements (as in the other sections) might be even better.

Perhaps something simple like

If two concurrent sessions run:

  BEGIN ISOLATION LEVEL REPEATABLE READ;
  SELECT count(*) FROM tab WHERE name = 'alice';
  /* if the result is <> 0, rollback */
  INSERT INTO table (name) VALUES ('alice');
  COMMIT;

you could end up with two rows with the same name, which could not
happen in a serial execution of the transactions.

Yours,
Laurenz Albe



pgsql-docs by date:

Previous
From: Will Mortensen
Date:
Subject: Re: [PATCH] Attempt to clarify example of serialization anomaly
Next
From: B M
Date:
Subject: large scale reliable software system