BEGIN; BEGIN SELECT * FROM aircrafts_tmp WHERE range > 6000

BEGIN
UPDATE aircrafts_tmp
SET range = 6100
WHERE aircraft_code = '320';
UPDATE 1
Сразу завершим вторую транзакцию, чтобы первая транзакция увидела эти из-
менения.
END;
COMMIT
На первом терминале повторим ту же самую выборку:
SELECT * FROM aircrafts_tmp WHERE range > 6000;
aircraft_code |
model
| range
---------------+-----------------+-------
773
| Boeing 777-300 | 11100
763
| Boeing 767-300 | 7900
319
| Airbus A319-100 | 6700
320
| Airbus A320-200 | 6100
(4 строки)
Транзакция еще не завершилась, но она уже увидела новую строку, обновлен-
ную зафиксированной параллельной транзакцией. Теперь эта строка стала соот-
ветствовать условию выборки. Таким образом, не изменяя критерий выборки,
мы получили другое множество строк.
Завершим теперь и первую транзакцию:
END;
COMMIT
Задание: модифицируйте этот эксперимент: вместо операции UPDATE исполь-
зуйте операцию INSERT.
5. В тексте главы была рассмотрена команда SELECT ... FOR UPDATE, выполняющая
блокировку на уровне отдельных строк. Организуйте две параллельные тран-
закции с уровнем изоляции READ COMMITTED и выполните с ними ряд экспе-
риментов. В первой транзакции заблокируйте некоторое множество строк, от-
бираемых с помощью условия WHERE. А во второй транзакции изменяйте усло-
вие выборки таким образом, чтобы выбираемое множество строк:
– являлось подмножеством множества строк, выбираемых в первой транзак-
ции;
– являлось надмножеством множества строк, выбираемых в первой транзак-
ции;
– пересекалось с множеством строк, выбираемых в первой транзакции;
– не пересекалось с множеством строк, выбираемых в первой транзакции.
222

Наблюдайте за поведением команд выборки в каждой транзакции. Попробуйте
обобщить ваши наблюдения.
6. Самостоятельно ознакомьтесь с предложением FOR SHARE команды SELECT и
выполните необходимые эксперименты. Используйте документацию: раздел
13.3.2 «Блокировки на уровне строк» и описание команды SELECT.
7. В тексте главы для иллюстрации изучаемых концепций мы создавали только две
параллельные транзакции. Попробуйте воспроизвести представленные экспе-
рименты, создав три или даже четыре параллельные транзакции.
8.* В тексте главы была рассмотрена транзакция для выполнения бронирования
билетов. Для нее был выбран уровень изоляции READ COMMITTED.
Как вы думаете, если одновременно будут производиться несколько операций
бронирования, то, может быть, имеет смысл «ужесточить» уровень изоляции до
SERIALIZABLE? Или нет необходимости это делать? Обдумайте и вариант с ис-
пользованием явных блокировок. Обоснуйте ваш ответ.
9.* В разделе документации 13.2.3 «Уровень изоляции Serializable» сказано, что ес-
ли поиск в таблице осуществляется последовательно, без использования индек-
са, тогда на всю таблицу накладывается так называемая предикатная блокиров-
ка. Такой подход приводит к увеличению числа сбоев сериализации. В качестве
контрмеры можно попытаться использовать индексы. Конечно, если таблица
совсем небольшая, то может и не получиться заставить PostgreSQL использовать
поиск по индексу. Тем не менее, давайте выполним следующий эксперимент.
Для его проведения создадим специальную таблицу, в которой будет всего два
столбца: один — числовой, а второй — текстовый. Значения во втором столб-
це будут иметь вид: LOW1, LOW2, ..., HIGH1, HIGH2, ... Назовем эту таблицу —
modes. Добавим в нее такое число строк, которое сделает очень вероятным ис-
пользование индекса при выполнении операций обновления строк и, соответ-
ственно, отсутствие предикатной блокировки всей таблицы. О том, как узнать,
используется ли индекс при выполнении тех или иных операций, написано в
главе 10.

жүктеу/скачать 3,05 Mb.

Достарыңызбен бөлісу: