Как стать автором
Обновить
188.35
Postgres Professional
Разработчик СУБД Postgres Pro
Сначала показывать

Блокировки в PostgreSQL: 2. Блокировки строк

Время на прочтение14 мин
Количество просмотров84K
В прошлый раз мы говорили о блокировках на уровне объектов, в частности — о блокировках отношений. Сегодня посмотрим, как в PostgreSQL устроены блокировки строк и как они используются вместе с блокировками объектов, поговорим про очереди ожидания и про тех, кто лезет без очереди.



Блокировки строк


Устройство


Напомню несколько важных выводов из прошлой статьи.

  • Блокировка должна существовать где-то в разделяемой памяти сервера.
  • Чем выше гранулярность блокировок, тем меньше конкуренция (contention) среди одновременно работающих процессов.
  • С другой стороны, чем выше гранулярность, тем больше места в памяти занимают блокировки.

Нам безусловно хочется, чтобы изменение одной строки не приводило к блокировке других строк той же таблицы. Но и заводить на каждую строку по собственной блокировке мы не можем себе позволить.

Есть разные пути решения этой проблемы. В некоторых СУБД происходит повышение уровня блокировки: если блокировок уровня строк становится слишком много, они заменяются одной более общей блокировкой (например, уровня страницы или всей таблицы).

Как мы увидим позже, в PostgreSQL такой механизм тоже применяется, но только для предикатных блокировок. С блокировками строк дело обстоит иначе.
Читать дальше →

Блокировки в PostgreSQL: 1. Блокировки отношений

Время на прочтение14 мин
Количество просмотров120K
Два предыдущих цикла статей были посвящены изоляции и многоверсионности и журналированию.

В этом цикле мы поговорим о блокировках (locks). Я буду придерживаться этого термина, но в литературе может встретиться и другой: замóк.

Цикл будет состоять из четырех частей:

  1. Блокировки отношений (эта статья);
  2. Блокировки строк;
  3. Блокировки других объектов и предикатные блокировки;
  4. Блокировки в оперативной памяти.

Материал всех статей основан на учебных курсах по администрированию, которые делаем мы с Павлом pluzanov, но не повторяет их дословно и предназначен для вдумчивого чтения и самостоятельного экспериментирования.
Читайте и другие серии.

Индексы:

  1. Механизм индексирования;
  2. Интерфейс метода доступа, классы и семейства операторов;
  3. Hash;
  4. B-tree;
  5. GiST;
  6. SP-GiST;
  7. GIN;
  8. RUM;
  9. BRIN;
  10. Bloom.

Изоляция и многоверсионность:

  1. Изоляция, как ее понимают стандарт и PostgreSQL;
  2. Слои, файлы, страницы — что творится на физическом уровне;
  3. Версии строк, виртуальные и вложенные транзакции;
  4. Снимки данных и видимость версий строк, горизонт событий;
  5. Внутристраничная очистка и HOT-обновления;
  6. Обычная очистка (vacuum);
  7. Автоматическая очистка (autovacuum);
  8. Переполнение счетчика транзакций и заморозка.

Журналирование:

  1. Буферный кеш;
  2. Журнал предзаписи — как устроен и как используется при восстановлении;
  3. Контрольная точка и фоновая запись — зачем нужны и как настраиваются;
  4. Настройка журнала — уровни и решаемые задачи, надежность и производительность.


Читать дальше →

WAL в PostgreSQL: 4. Настройка журнала

Время на прочтение17 мин
Количество просмотров38K
Итак, мы познакомились с устройством буферного кеша и на его примере поняли, что когда при сбое пропадает содержимое оперативной памяти, для восстановления необходим журнал предзаписи. Размер необходимых файлов журнала и время восстановления ограничены благодаря периодически выполняемой контрольной точке.

В предыдущих статьях мы уже посмотрели на довольно большое число важных настроек, так или иначе относящихся к журналу. В этой статье (последней в этом цикле) мы рассмотрим те вопросы настройки, которые еще не обсуждались: уровни журнала и их назначение, а также надежность и производительность журналирования.

Уровни журнала


Основная задача журнала предзаписи — обеспечить возможность восстановления после сбоя. Но, если уж все равно приходится вести журнал, его можно приспособить и для других задач, добавив в него некоторое количество дополнительной информации. Есть несколько уровней журналирования. Они задаются параметром wal_level и организованы так, что журнал каждого следующего уровня включает в себя все, что попадает в журнал предыдущего уровня, плюс еще что-то новое.
Читать дальше →

WAL в PostgreSQL: 3. Контрольная точка

Время на прочтение12 мин
Количество просмотров45K
Мы уже познакомились с устройством буферного кеша — одного из основных объектов в разделяемой памяти, — и поняли, что для восстановления после сбоя, когда содержимое оперативной памяти пропадает, нужно вести журнал предзаписи.

Нерешенная проблема, на которой мы остановились в прошлый раз, состоит в том, что неизвестно, с какого момента можно начинать проигрывание журнальных записей при восстановлении. Начать с начала, как советовал Король из Алисы, не получится: невозможно хранить все журнальные записи от старта сервера — это потенциально и огромный объем, и такое же огромное время восстановления. Нам нужна такая постепенно продвигающаяся вперед точка, с которой мы можем начинать восстановление (и, соответственно, можем безопасно удалять все предшествующие журнальные записи). Это и есть контрольная точка, о которой сегодня пойдет речь.

Контрольная точка


Каким свойством должна обладать контрольная точка? Мы должны быть уверены, что все журнальные записи, начиная с контрольной точки, будут применяться к страницам, записанным на диск. Если бы это было не так, при восстановлении мы могли бы прочитать с диска слишком старую версию страницы и применить к ней журнальную запись, и тем самым безвозвратно повредили бы данные.
Читать дальше →

SQL: решение задачи о рабочем времени

Время на прочтение13 мин
Количество просмотров30K

Здравствуйте, в эфире опять Радио SQL! Сегодня у нас решение задачи, которую мы передавали в нашем предыдущем эфире, и обещали разобрать в следующий раз. И вот этот следующий раз наступил.


Задача вызвала живой отклик у гуманоидов галактики Млечный путь (и неудивительно, с их-то трудовым рабством, которое они до сих пор почитают за благо цивилизации). К сожалению, на третьей планете отложили запуск космической обсерватории «Спектр-РГ» в конце июля 2019 года РХ (летоисчисление местное), с помощью которого планировалось транслировать эту передачу. Пришлось искать альтернативные пути передачи, что привело к небольшому опозданию сигнала. Но всё хорошо, что хорошо кончается.



Сразу скажу, что в разборе задачи не будет никакой магии, не надо искать тут откровений или ждать какой-то особо эффективной (или особо какой-нибудь в любом другом смысле) реализации. Это просто разбор задачи. В нём те, кто не знает, как подступаться к решению таких задач, смогут посмотреть, как же их решать. Тем более, что ничего страшного тут нет.

Сделать шаг

WAL в PostgreSQL: 2. Журнал предзаписи

Время на прочтение8 мин
Количество просмотров74K
В прошлый раз мы познакомились с устройством одного из важных объектов разделяемой памяти, буферного кеша. Возможность потери информации из оперативной памяти — основная причина необходимости средств восстановления после сбоя. Сегодня мы поговорим про эти средства.

Журнал


Увы, чудес не бывает: чтобы пережить потерю информации в оперативной памяти, все необходимое должно быть своевременно записано на диск (или другое энергонезависимое устройство).

Поэтому сделано вот что. Вместе с изменением данных ведется еще и журнал этих изменений. Когда мы что-то меняем на странице в буферном кеше, мы создаем в журнале запись об этом изменении. Запись содержит минимальную информацию, достаточную для того, чтобы при необходимости изменение можно было повторить.

Чтобы это работало, журнальная запись в обязательном порядке должна попасть на диск до того, как туда попадет измененная страница. Отсюда и название: журнал предзаписи (write-ahead log).

Если происходит сбой, данные на диске оказываются в рассогласованном состоянии: какие-то страницы были записаны раньше, какие-то — позже. Но остается и журнал, который можно прочитать и выполнить повторно те операции, которые уже были выполнены до сбоя, но результат которых не успел дойти до диска.
Читать дальше →

Дайджест новостей из мира PostgreSQL. Выпуск №16

Время на прочтение10 мин
Количество просмотров5.4K


Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Главная новость июня



EnterpriseDB приобретена инвестиционным фондом Great Hill Partners. Сумма сделки не разглашается. Майкл Стоунбрейкер назначен техническим советником. Энди Палмер вошел в совет директоров EDB. Он известный ИТ-инвестор, сооснователь Vertica и автор главы в книге Making Databases Work: The Pragmatic Wisdom of Michael Stonebraker. Great Hill Partners — частный (непубличный) фонд, управляющий $2.7 млрд. Событие не менее впечатляющее, чем недавняя покупка Citus Microsoft-ом: из 5 участников Core Team двое сотрудники EDB.

Релизы



PostgreSQL 11.4, 10.9, 9.6.14, 9.5.18, 9.4.23 и 12 Beta 2

Этих релизов ждали не из-за новых фич, а из-за того, что надо было закрывать обнаруженную дырку в безопасности под кодовым названием CVE-2019-10164. Любой прошедший проверку при аутентификации по методу scram-sha-256 пользователь мог переполнить буфер в стеке, сменяя свой пароль на специально сконструированную строку. Этим способом можно было не только уронить сервер, но и выполнить произвольный код от имени пользователя ОС, запускающего PostgreSQL.

Подобная возможность переполнения существовала и в libpq, и эксплуатируя её, подставной сервер мог уронить клиентское приложение или выполнить коварный код на клиенте от имени пользователя, запускавшего это приложение.

Эта уязвимость проявилась только в относительно новых версиях PostgreSQL: 10 и выше, когда появилась SCRAM-аутентификация. На сайте сообщества можно увидеть «особую благодарность» Александру Лахину (Postgres Professional), который обнаружил проблему.

Можно почитать статью на эту тему: eVOL Monkey. Who's affected and how to protect your systems.

Postgres Pro Standard 11.4.1, 10.9.1, 9.6.14.1, 9.5.17.1 и Postgres Pro Enterprise 11.4.1

В этих версиях дыра в безопасности уже закрыта. Об этом и о других багфиксах можно прочитать в документации к соответствующей версии.
Читать дальше →

WAL в PostgreSQL: 1. Буферный кеш

Время на прочтение13 мин
Количество просмотров80K
Предыдущий цикл был посвящен изоляции и многоверсионности PostgreSQL, а сегодня мы начинаем новый — о механизме журналирования (write-ahead logging). Напомню, что материал основан на учебных курсах по администрированию, которые делаем мы с Павлом pluzanov, но не повторяет их дословно и предназначен для вдумчивого чтения и самостоятельного экспериментирования.

Этот цикл будет состоять из четырех частей:


Читайте и другие серии.

Индексы:

  1. Механизм индексирования;
  2. Интерфейс метода доступа, классы и семейства операторов;
  3. Hash;
  4. B-tree;
  5. GiST;
  6. SP-GiST;
  7. GIN;
  8. RUM;
  9. BRIN;
  10. Bloom.

Изоляция и многоверсионность:

  1. Изоляция, как ее понимают стандарт и PostgreSQL;
  2. Слои, файлы, страницы — что творится на физическом уровне;
  3. Версии строк, виртуальные и вложенные транзакции;
  4. Снимки данных и видимость версий строк, горизонт событий;
  5. Внутристраничная очистка и HOT-обновления;
  6. Обычная очистка (vacuum);
  7. Автоматическая очистка (autovacuum);
  8. Переполнение счетчика транзакций и заморозка.

Блокировки:

  1. Блокировки отношений;
  2. Блокировки строк;
  3. Блокировки других объектов и предикатные блокировки;
  4. Блокировки в оперативной памяти.


Читать дальше →

SQL: задача о рабочем времени: разбор полётов

Время на прочтение3 мин
Количество просмотров9.1K
В эфире опять Радио SQL! Сегодня у нас совсем краткий выпуск, посвящённый подведению итогов решения задачки участниками хабросообщества. Я обещал разыграть небольшой приз, так что подвести итоги лучше небольшой, но всё же статьёй. Дописать строчку в оригинальную статью (что я, впрочем, тоже сделал) — было явно недостаточно, заинтересованные лица могут пропустить такое подведение итогов. Поэтому подстраивайте свои ложементы и вытягивайте омматофоры, мы начинаем!

Пиу-пиу!

Не очень большие данные

Время на прочтение21 мин
Количество просмотров22K
В статье будут рассмотрены возможности, предоставляемые встроенным или декларативным секционированием в 12 версии PostgreSQL. Демонстрация подготовлена для одноименного доклада на конференции HighLoad++Siberia 2019 (upd: появилось видео с докладом).

Все примеры выполнены на недавно появившейся бета-версии:

=> SELECT version();
                                                     version                                                      
------------------------------------------------------------------------------------------------------------------
 PostgreSQL 12beta1 on i686-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609, 32-bit
(1 row)
Читать дальше →

MVCC в PostgreSQL-8. Заморозка

Время на прочтение12 мин
Количество просмотров24K
Мы начали с вопросов, связанных с изоляцией, сделали отступление про организацию данных на низком уровне, подробно поговорили о версиях строк и о том, как из версий получаются снимки данных.

Затем мы рассмотрели разные виды очистки: внутристраничную (вместе с HOT-обновлениями), обычную и автоматическую.

И добрались до последней темы этого цикла. Сегодня мы поговорим о проблеме переполнения счетчика транзакций (transaction id wraparound) и заморозке.
Читать дальше →

Игра в прятки с оптимизатором. Гейм овер, это CTE PostgreSQL 12

Время на прочтение6 мин
Количество просмотров38K


Эта статья — продолжение рассказа о новом в PostgreSQL 12. Мы уже разобрали SQL/JSON (патч JSONPath) в статье «Что заморозили на feature freeze 2019. Часть I. JSONPath», теперь очередь CTE.

CTE


CTE это Common Table Expression — общие табличные выражения, их еще называют конструкциями с WITH. Фактически это создание временных таблиц, но существующих только для одного запроса, а не для сессии. К ним можно обращаться внутри этого запроса. Такой запрос хорошо читается, он понятен, его легко видоизменять, если потребуется. Это очень востребованная вещь, и она в PostgreSQL давно.

Но удобства могут обойтись дорого. Проблемы связаны с материализацией выражения после AS внутри конструкции WITH… AS (). Его еще называют внутренним выражением и вычисляют перед тем, как начать вычисление остального, его нельзя встроить в запрос верхнего уровня (no inlining). Планирование этого выражения происходит без учета остальной части запроса. Такое поведение называют барьером для оптимизации, или fencing. Кроме того, сама материализация требует под себя work_mem. И если выборка большая, то начинаются проблемы (об этом, например, есть в докладе Ивана Фролкова на PGConf 2019).
Читать дальше →

MVCC-7. Автоочистка

Время на прочтение11 мин
Количество просмотров50K
Напомню, что мы начали с вопросов, связанных с изоляцией, сделали отступление про организацию данных на низком уровне, подробно поговорили о версиях строк и о том, как из версий получаются снимки данных.

Затем мы рассмотрели внутристраничную очистку (и HOT-обновления), обычную очистку, ну а сегодня посмотрим на автоматическую очистку.

Автоочистка (autovacuum)


Мы уже говорили о том, что обычная очистка в нормальных условиях (когда никто не удерживает надолго горизонт транзакций) должна справляться со своей работой. Вопрос в том, как часто ее вызывать.

Если очищать изменяющуюся таблицу слишком редко, она вырастет в размерах больше, чем хотелось бы. Кроме того, для очередной очистки может потребоваться несколько проходов по индексам, если изменений накопилось слишком много.

Если очищать таблицу слишком часто, то вместо полезной работы сервер будет постоянно заниматься обслуживанием — тоже нехорошо.

Заметим, что запуск обычной очистки по расписанию никак не решает проблему, потому что нагрузка может изменяться со временем. Если таблица стала обновляться активней, то и очищать ее надо чаще.

Автоматическая очистка — как раз тот самый механизм, который позволяет запускать очистку в зависимости от активности изменений в таблицах.
Читать дальше →

Профессиональный Postgres

Время на прочтение17 мин
Количество просмотров16K
Мы продолжаем публиковать видео и расшифровки лучших докладов с конференции PGConf.Russia 2019. Доклад Олега Бартунова на тему «Профессиональный Postgres» открывал пленарную часть конференции. В нем раскрыта история СУБД Postgres, российский вклад в разработку, особенности архитектуры.

Предыдущие материалы этой серии: «Типичные ошибки при работе с PostgreSQL» Ивана Фролкова, части 1 и 2.



Я буду рассказывать про профессиональный Postgres. Прошу не путать с компанией, которую я представляю сейчас — Postgres Professional.



Я действительно буду говорить о том, как Postgres, начинавшийся как любительская академическая разработка, стал профессиональным — таким, как мы его видим сейчас. Выскажу исключительно свое персональное мнение, оно не отражает мнение ни нашей компании, ни каких-либо групп.
Читать дальше →

MVCC-6. Очистка

Время на прочтение13 мин
Количество просмотров61K
Мы начали с вопросов, связанных с изоляцией, сделали отступление про организацию данных на низком уровне, затем подробно поговорили о версиях строк и о том, как из версий получаются снимки данных.

В прошлый раз мы поговорили о HOT-обновлениях и внутристраничной очистке, а сегодня займемся всем известной обычной очисткой, vacuum vulgaris. Да, про нее написано уже столько всего, что вряд ли я скажу что-то новое, но полнота картины требует жертв. Терпите.

Обычная очистка (vacuum)


Что делает очистка


Внутристраничная очистка выполняется быстро, но освобождает только часть места. Она работает в пределах одной табличной страницы и не затрагивает индексы.

Основная, «обычная» очистка выполняется командой VACUUM и ее мы будем называть просто очисткой (а про автоочистку мы будем говорить отдельно).

Итак, очистка обрабатывает таблицу полностью. Она вычищает не только ненужные версии строк, но и ссылки на них из всех индексов.

Обработка происходит параллельно с другой активностью в системе. Таблица и индексы при этом могут использоваться обычным образом и для чтения, и для изменения (однако одновременное выполнение таких команд, как CREATE INDEX, ALTER TABLE и некоторых других будет невозможно).

В таблице просматриваются только те страницы, в которых происходила какая-то активность. Для этого используется карта видимости (напомню, что в ней отмечены страницы, содержащие только достаточно старые версии строк, которые гарантированно видимы во всех снимках данных). Обрабатываются только страницы, не отмеченные в карте, а сама карта при этом обновляется.

В процессе работы обновляется и карта свободного пространства, чтобы отразить появившееся свободное места в страницах.
Читать дальше →

Что заморозили на feature freeze 2019. Часть I. JSONPath

Время на прочтение9 мин
Количество просмотров7.6K

После комитфеста 2019-03 произошла заморозка функциональности (feature freeze). У нас это почти традиционная рубрика: о прошлогодней заморозке мы уже писали. Теперь итоги 2019: что из нового войдет в PostgreSQL 12. В этой части обзора, посвященной JSONPath, используются в том числе примеры и фрагменты из доклада «Postgres 12 в этюдах», который прочитал Олег Бартунов на Saint Highload++ в СПБ 9 апреля сего года.
Читать дальше →

SQL: задача о рабочем времени

Время на прочтение3 мин
Количество просмотров24K
Здравствуйте, в эфире снова Радио SQL! Разминайте ганглии, расправляйте псевдоподии (или наоборот?) и настраивайтесь на нашу гравитационную волну!

Бдымц!

MVCC-5. Внутристраничная очистка и HOT

Время на прочтение9 мин
Количество просмотров24K
Напомню, что мы рассмотрели вопросы, связанные с изоляцией, сделали отступление про организацию данных на низком уровне, а затем подробно поговорили о версиях строк и о том, как из версий получаются снимки данных.

Сегодня займемся двумя довольно тесно связанными вопросами: внутристраничной очисткой и HOT-обновлениями. Оба механизма можно отнести к разряду оптимизаций; они важны, но в пользовательской документации практически не освещены.

Внутристраничная очистка при обычных обновлениях


При обращении к странице — как при обновлении, так и при чтении — может происходить быстрая внутристраничная очистка, если PostgreSQL поймет, что место на странице заканчивается. Это происходит в двух случаях.

  1. Ранее выполненное на этой странице обновление (UPDATE) не обнаружило достаточно места, чтобы разместить новую версию строки на той же странице. Такая ситуация запоминается в заголовке страницы, и в следующий раз страница очищается.
  2. Страница заполнена больше, чем на fillfactor. При этом очистка происходит сразу, не откладывая на следующий раз.
Читать дальше →

Об одной уязвимости, которой нет

Время на прочтение4 мин
Количество просмотров10K

image
В конце марта 2019 года американская компания Trustwave, занимающаяся кибербезопасностью и сервисами по защите от угроз, опубликовала сообщение об уязвимости в СУБД PostgreSQL, которая присутствует во всех версиях, начиная с версии PostgreSQL 9.3 по версию 11.2. Эта уязвимость была зарегистрирована в базе данных уязвимостей информационной безопасности CVE (Common Vulnerabilities and Exposures ) под номером CVE-2019-9193. Это сообщение вызвало большой переполох, так как по системе оценок уязвимостей CVSS (Common Vulnerability Scoring System) данная уязвимость получила рейтинг 9.0 по 10-балльной шкале.

Читать дальше →

MVCC-4. Снимки данных

Время на прочтение9 мин
Количество просмотров34K
Рассмотрев вопросы, связанные с изоляцией, и сделав отступление об организации данных на низком уровне, мы в прошлый раз подробно поговорили о версиях строк и проследили, как изменяется служебная информация в заголовке версии при различных операциях.

Сегодня мы посмотрим на то, как из версий строк получаются согласованные снимки данных.

Что такое снимок данных


Физически в страницах данных могут находиться несколько версий одной и той же строки. При этом каждая транзакция должна видеть только одну (или ни одной) версию каждой строки так, чтобы вместе они составляли согласованную в ACID-смысле картину данных на определенный момент времени.

Изоляция в PostgreSQL строится на основе снимков данных (snapshot): каждая транзакция работает со своим снимком данных, который «содержит» данные, которые были зафиксированы до момента создания снимка, и не «содержит» еще не зафиксированные на этот момент данные. Мы уже видели, что изоляция при этом получается более строгая, чем требует стандарт, но не лишенная аномалий.
Читать дальше →

Информация

Сайт
www.postgrespro.ru
Дата регистрации
Дата основания
Численность
201–500 человек
Местоположение
Россия
Представитель
Иван Панченко