Благодаря посту Внутренности PostgreSQL: ProcArray и CLOG мы узнали, как PostgreSQL определяет состояние транзакции по ее идентификатору, или XID. Однако из статьи Внутренности PostgreSQL: страницы и кортежи мы также помним, что XID является 32-х битным числом. Несложными математическими расчетами несложно понять, что даже при скромных нагрузках (~1000 TPS), уникальные XID’ы могут закончится за несколько месяцев. Давайте разберемся, как PostgreSQL решает эту проблему.
PostgreSQL хранит данные в страницах, а страницы кэшируются в разделяемых буферах. Казалось бы, в случае аварийной остановки грязные страницы не будут записаны на диск, и часть данных пропадет. Чтобы такого не происходило, СУБД пишет журнал предзаписи, он же Write Ahead Log, или WAL.
Когда-то давно мы научились собирать PostgreSQL из исходников. Тогда в проекте использовалась система сборки Autotools. Однако в PostgreSQL 16, который на момент написания этих строк еще находится в разработке, была добавлена поддержка альтернативной системы сборки, Meson. Давайте разберемся, как ею пользоваться.
Ранее мы установили (часть один, часть два) что PostgreSQL хранит все данные в страницах, размер которых по умолчанию равен 8 Кб. Однако напрямую читать и писать страницы с/на диск было бы дороговато. Поэтому используется кэш в разделяемой памяти. Он называется разделяемые буферы, или shared buffers. Попробуем разобраться, как именно устроен этот кэш.
Рассмотренные нами ранее ProcArray и CLOG реализованы поверх разделяемой памяти и LWLocks. Но напрямую использовать данные примитивы нам пока не доводилось. А жаль, ведь примитивы эти полезные, особенно в расширениях PostgreSQL. Давайте же заполним этот пробел.
Оконные функции (window functions) — это фича, позволяющая производить манипуляции между строками, возвращаемыми одним SQL-запросом. Похоже на GROUP BY, но, в отличие от него, строки не объединяются в одну. Есть задачи, в которых оконные функции исключительно удобны. Например, когда нужно показать некие значения (выручку, посещаемость) за месяц, и рядом с ними — насколько это больше или меньше по сравнению с прошлым месяцем.
Благодаря статье Внутренности PostgreSQL: страницы и кортежи мы узнали, что каждый кортеж в PostgreSQL хранит t_xmin и t_xmax — XIDы транзакций создавшей и удалившей кортеж соответственно. Зная XID текущей транзакции, ее уровень изоляции, а также состояние транзакций t_xmin и t_xmax, СУБД способна определить, виден ли кортеж в текущей транзакции или нет. Узнать состояние транзакции по ее XID можно при помощи ProcArray и CLOG.
Ранее мы разобрались, как PostgreSQL хранит страницы на диске, и как можно посмотреть их содержимое при помощи pageinspect. Но возникает вот какой вопрос. Если размер страницы составляет несколько килобайт, и кортежи не могут занимать несколько страниц, то как СУБД хранит атрибуты с типом TEXT? Ведь строки явно могут быть длиннее пары тысяч символов. Это возможно благодаря штуке под названием The Oversized-Attribute Storage Technique, или сокращенно TOAST.
Одна из возможностей PostgreSQL, которой часто пренебрегают — это NOTIFY и LISTEN. Данный механизм позволяет использовать РСУБД в роли брокера сообщений. NOTIFY/LISTEN обладает рядом полезных свойств, которых нет у прочих решений, таких, как RabbitMQ или Kafka.
Недавно мы разобрались, как PostgreSQL хранит данные на диске. Но как убедиться, что СУБД именно так и работает? Вдруг мы что-то упустили или недопоняли? Можно прочитать данные с диска с помощью утилиты hexdump и посмотреть, что там реально записано. Но это трудоемко, ведь все битики придется декодировать вручную. К счастью, с PostgreSQL идет расширение pageinspect, которое может декодировать битики за нас.