Все потоки

ПрофильСтатьи317Посты3Новости18Подписчики133K

@erogov 10 июл 2019 в 11:11

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

8 мин

97K

Блог компании Postgres ProfessionalPostgreSQL * SQL *

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

Журнал

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

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

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

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

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

+19

@Igor_Le 5 июл 2019 в 14:13

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

10 мин

5.5K

Блог компании Postgres ProfessionalPostgreSQL *

Мы продолжаем знакомить вас с самыми интересными новостями по 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

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

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

+13

@erogov 30 июн 2019 в 15:18

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

13 мин

97K

Блог компании Postgres ProfessionalPostgreSQL * SQL *

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

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

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

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

Индексы:

Механизм индексирования;

Интерфейс метода доступа, классы и семейства операторов;

Hash;

B-tree;

GiST;

SP-GiST;

GIN;

RUM;

BRIN;

Bloom.

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

Изоляция, как ее понимают стандарт и PostgreSQL;

Слои, файлы, страницы — что творится на физическом уровне;

Версии строк, виртуальные и вложенные транзакции;

Снимки данных и видимость версий строк, горизонт событий;

Внутристраничная очистка и HOT-обновления;

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

Автоматическая очистка (autovacuum);

Переполнение счетчика транзакций и заморозка.

Блокировки:

Блокировки отношений;

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

Блокировки других объектов и предикатные блокировки;

Блокировки в оперативной памяти.

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

+33

@bzq 26 июн 2019 в 11:18

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

3 мин

9.3K

Блог компании Postgres ProfessionalЗанимательные задачкиSQL * PostgreSQL *

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

+17

@pluzanov 19 июн 2019 в 14:16

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

21 мин

24K

Блог компании Postgres ProfessionalSQL * PostgreSQL *

В статье будут рассмотрены возможности, предоставляемые встроенным или декларативным секционированием в 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)

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

+29

@erogov 17 июн 2019 в 15:56

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

12 мин

30K

Блог компании Postgres ProfessionalPostgreSQL * SQL *

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

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

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

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

+17

@Igor_Le 13 июн 2019 в 11:42

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

6 мин

46K

Блог компании Postgres ProfessionalPostgreSQL *

Эта статья — продолжение рассказа о новом в 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).

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

+26

@erogov 6 июн 2019 в 10:41

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

11 мин

59K

Блог компании Postgres ProfessionalPostgreSQL * SQL *

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

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

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

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

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

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

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

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

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

+12

@Igor_Le 3 июн 2019 в 13:35

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

17 мин

17K

Блог компании Postgres ProfessionalPostgreSQL *

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

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

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

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

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

+27

@erogov 27 мая 2019 в 07:38

MVCC-6. Очистка

13 мин

72K

Блог компании Postgres ProfessionalPostgreSQL * SQL *

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

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

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

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

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

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

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

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

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

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

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

+20

@Igor_Le 23 мая 2019 в 10:35

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

9 мин

8K

Блог компании Postgres ProfessionalPostgreSQL *

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

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

+9

@bzq 21 мая 2019 в 08:41

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

3 мин

24K

Блог компании Postgres ProfessionalЗанимательные задачкиSQL * PostgreSQL *

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

+13

@erogov 14 мая 2019 в 09:30

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

9 мин

30K

Блог компании Postgres ProfessionalPostgreSQL * SQL *

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

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

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

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

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

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

+10

@vvp-ppg 23 апр 2019 в 10:53

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

4 мин

11K

Блог компании Postgres ProfessionalPostgreSQL *

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

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

+20

@erogov 19 апр 2019 в 07:39

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

9 мин

43K

Блог компании Postgres ProfessionalPostgreSQL * SQL *

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

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

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

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

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

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

+15

@Igor_Le 16 апр 2019 в 17:29

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

7 мин

5.6K

Блог компании Postgres ProfessionalPostgreSQL *

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

Новости

Главное событие месяца — это, конечно, Feature Freeze. Мартовский коммитфест закрыт. Основной облик версии PostgreSQL 12 определился. Дальше будут доработки и исправления, но не изменения в функциональности. О наиболее важных фичах 12 версии в ближайшее время мы сделаем отдельную публикацию.

Уязвима ли «уязвимость»

Под загадочным кодом CVE-2019-9193 скрывается политически важная для сообщества причина беспокойства. Речь о конструкции COPY… PROGRAM, появившейся еще в 9.3, которая дает возможность исполнять в запросе файлы ОС и писать в стандартный ввод или читать из стандартного вывода программы.

When a vulnerability is not a vulnerability

Однако, классик PostgreSQL Магнус Хагандер (Magnus Hagander) разъясняет в своем блоге:
Эта «уязвимость» эквивалентна тому факту, что в типичной Unix-системе вы можете залогиниться рутом и создавать или редактировать файлы, и исполнять команды как root. <...> Будучи суперюзером, можно запускать файлы в ОС отнюдь не только при помощи COPY… PROGRAM." <...> Итак, уязвимости в PostgreSQL нет, зато однозначно есть уязвимые инсталляции PostgreSQL.

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

+21

@erogov 5 апр 2019 в 21:24

MVCC-3. Версии строк

13 мин

59K

Блог компании Postgres ProfessionalPostgreSQL * SQL *

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

Заголовок

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

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

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

+19

@erogov 29 мар 2019 в 21:13

MVCC-2. Слои, файлы, страницы

12 мин

64K

Блог компании Postgres ProfessionalPostgreSQL * SQL *

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

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

Отношения (relations)

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

То, что таблица состоит из строк, не вызывает сомнений; для индекса это менее очевидно. Тем не менее, представьте B-дерево: оно состоит из узлов, которые содержат индексированные значения и ссылки на другие узлы или на табличные строки. Вот эти узлы и можно считать индексными строками — фактически, так оно и есть.

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

Все эти объекты в PostgreSQL называются общим словом отношение (по-английски relation). Слово крайне неудачное, потому что это термин из реляционной теории. Можно провести параллель между отношением и таблицей (представлением), но уж никак не между отношением и индексом. Но так уж сложилось: дают о себе знать академические корни PostgreSQL. Мне думается, что сначала так называли именно таблицы и представления, а остальное наросло со временем.

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

+33

@erogov 20 мар 2019 в 22:53

MVCC-1. Изоляция

25 мин

218K

Блог компании Postgres ProfessionalPostgreSQL * SQL *

Привет, Хабр! Этой статьей я начинаю серию циклов (или цикл серий? в общем, задумка грандиозная) о внутреннем устройстве PostgreSQL.

Материал будет основан на учебных курсах по администрированию, которые делаем мы с Павлом pluzanov. Смотреть видео не все любят (я точно не люблю), а читать слайды, пусть даже с комментариями, — совсем «не то».

Конечно, статьи не будут повторять содержание курсов один в один. Я буду говорить только о том, как все устроено, опуская собственно администрирование, зато постараюсь делать это более подробно и обстоятельно. И я верю в то, что такие знания полезны прикладному разработчику не меньше, чем администратору.

Ориентироваться я буду на тех, кто уже имеет определенный опыт использования PostgreSQL и хотя бы в общих чертах представляет себе, что к чему. Для совсем новичков текст будет тяжеловат. Например, я ни слова не скажу о том, как установить PostgreSQL и запустить psql.

Вещи, о которых пойдет речь, не сильно меняются от версии к версии, но использовать я буду текущий, 11-й «ванильный» PostgreSQL.

Первый цикл посвящен вопросам, связанным с изоляцией и многоверсионностью, и план его таков:

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

Ну, поехали.

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

+31

@Igor_Le 18 мар 2019 в 09:49

Типичные ошибки при работе с PostgreSQL. Часть 2

8 мин

54K

Блог компании Postgres ProfessionalPostgreSQL *

Мы продолжаем публиковать видео и расшифровки лучших докладов с конференции PGConf.Russia 2019. В первой части доклада Ивана Фролкова речь шла о непоследовательном именовании, о constraints, о том, где лучше сосредоточить логику — в базе или в приложении. В этой части вас ждет разбор обработки ошибок, конкурентного доступа, неотменяемых операций, CTE и JSON.

Расскажу такую историю. Наш клиент говорит: «Медленно работает база, а наше приложение занимается обслуживаем населения. Мы боимся, что нас тут поднимут на вилы». Выяснилось, что у них было очень много процессов в состоянии idle in transaction. Приложение начало транзакцию, ничего не делает, но и транзакцию не завершает. Если вы взаимодействуете с какими-то внешними сервисами, то, в принципе, это нормальная ситуация. Другое дело, что если у вас состояние idle in transaction длится долго (больше минуты уже подозрительно), то это плохо потому, что PostgreSQL очень не любит долгие транзакции: VACUUM не сможет почистить все те строки, которые он мог бы увидеть, и долго висящая транзакция эффективно блокирует VACUUM. Начинают разбухать таблицы, индексы становятся всё менее эффективными.

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

+30

1 2 ...

12