Некорректное пояснение к примеру в разделе 13.2.1

From: Алексей Снытко <asnytko(dot)krk(at)gmail(dot)com>
To: pgsql-docs(at)postgresql(dot)org
Subject: Некорректное пояснение к примеру в разделе 13.2.1
Date: 2018-06-27 05:05:17
Message-ID: CAF+QRgkFacxcfH3evASRjRi3aXqAte4QS+G43t6DDGRdf=zFCA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

Добрый день!

Документация к PostgreSQL 9.5 - 10, раздел 13.2.1 "Уровень изоляции Read
Committed".

В данном разделе приведен пример с таблицей website, после него следует
объяснение логики выполнения:

*"Команда DELETE не сделает ничего, даже несмотря на то, что строка с
website.hits = 10 была в таблице и до, и после выполнения UPDATE. Это
происходит потому, что строка со значением 9 до изменения пропускается, а
когда команда UPDATE завершается и DELETE получает освободившуюся
блокировку, строка с 10 теперь содержит 11, а это значение уже не
соответствует условию"*

Это не соответствует описанию логики уровня изоляции Read Committed,
который приведен выше:

*"Однако SELECT видит результаты изменений, внесённых ранее в этой же
транзакции, даже если они ещё не зафиксированы"*

Если создать таблицу website, состоящую из одного столбца hits, и заполнить
ее двумя строками со значениями 9 и 10, как описано в примере, то при
выполнении транзакции

*BEGIN; *
*UPDATE website SET hits = hits + 1; *
*DELETE FROM website WHERE hits = 10; *
*COMMIT;*

команда DELETE удалит одну из строк таблицы, которая на момент начала
транзакции имела значение 9, а после выполнения команды UPDATE значение 10.
Соответственно, в таблице website должна остаться только одна строка со
значением 10.

Это не ошибка в переводе - документация на английском языке содержит тот же
пример и некорректное пояснение к нему.

--
С уважением,
Алексей Снытко

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Alexander Lakhin 2018-06-27 06:27:27 Re: PDF build warnings
Previous Message Tom Lane 2018-06-26 23:10:01 Re: PDF build warnings