Обсуждение: [PATCH] Attempt to clarify example of serialization anomaly

Поиск
Список
Период
Сортировка

[PATCH] Attempt to clarify example of serialization anomaly

От
Will Mortensen
Дата:
(sorry to the CCs for sending this twice)

This example has been pointed out as confusing in multiple places, e.g.:

 * https://postgrespro.com/list/thread-id/1845118
 * https://dba.stackexchange.com/a/43951
 * https://stackoverflow.com/a/50733640 ("this paragraph is dark")

As mentioned in those links, it seems to attempt to summarize the
wiki's example at https://wiki.postgresql.org/wiki/SSI#Deposit_Report
. I'm not sure if/how to link to the wiki from the docs, so here is my
humble attempt to summarize it concisely and (hopefully) clearly.

Alternatively, this example could be removed in favor of a reference
to the Serializable section and its example.

Вложения

Re: [PATCH] Attempt to clarify example of serialization anomaly

От
Will Mortensen
Дата:
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.

Thanks Bruce for applying my more trivial patches. :-)

Вложения

Re: [PATCH] Attempt to clarify example of serialization anomaly

От
Laurenz Albe
Дата:
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