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.
Это не ошибка в переводе - документация на английском языке содержит тот же
пример и некорректное пояснение к нему.
--
С уважением,
Алексей Снытко
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 |