Записки программиста

Когда-то давно мы научились собирать PostgreSQL из исходников. Тогда в проекте использовалась система сборки Autotools. Однако в PostgreSQL 16, который на момент написания этих строк еще находится в разработке, была добавлена поддержка альтернативной системы сборки, Meson. Давайте разберемся, как ею пользоваться.

Рассмотренные нами ранее ProcArray и CLOG реализованы поверх разделяемой памяти и LWLocks. Но напрямую использовать данные примитивы нам пока не доводилось. А жаль, ведь примитивы эти полезные, особенно в расширениях PostgreSQL. Давайте же заполним этот пробел.

Наиболее простой способ работы с таблицами из расширений PostgreSQL заключается в использовании Server Programming Interface (SPI). С этим интерфейсом мы познакомились в рамках статьи Учимся писать расширения на языке C для PostgreSQL. Однако SPI имеет накладные расходы на парсинг и планирование запросов. Поэтому в простых сценариях выгоднее работать с таблицами напрямую. Звучит страшновато, но на самом деле это не так сложно.

Как мы недавно выяснили, в PostgreSQL есть исключения. Но использовать исключения в языке С, где нет ни автоматического управления памятью, ни умных указателей, не кажется хорошей идеей. Так вот, оказывается, что вместо умных указателей PostgreSQL предлагает совершенно другой механизм — контексты памяти (memory contexts). Давайте же разберемся, что это такое, и чем помогает в работе с исключениями.

Хотелось бы продолжить рассказ о расширениях PostgreSQL и поговорить о логировании и исключениях. Рассматривать их нужно вместе, поскольку в PostgreSQL это связанные механизмы. Хотя ранее мы уже и использовали макрос elog(), тема была затронута лишь поверхностно.

В рамках статьи Учимся писать расширения на языке C для PostgreSQL мы познакомились со структурой расширений для постгреса, узнали, как писать для них тесты, и даже затронули вопрос обновления расширений и использования интерфейса SPI. Но заметка вышла из серии «с места в карьер», без глубокого погружения в детали. А между тем, погружаться есть во что. Хотелось бы заполнить кое-какие пробелы, и начать, пожалуй, следует с Datum и вызова сторонних функций.

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

Ранее в этом блоге многократно упоминались чипы производства компании FTDI, такие, как FT232RL и FT2232HL — смотри заметки раз, два и далее по ссылкам. В частности, было сказано, что этими чипами можно управлять с компьютера, что позволяет использовать их, например, в качестве программатора. При этом чипы FTDI поддерживают несколько режимов работы. Далее будет рассмотрен, пожалуй, самый простой режим под названием bitbang.

Народная мудрость гласит, что правильно сделать шифрование в своем приложении крайне непросто. Свой велосипед почти наверняка будет содержать крайне неочевидные простому смертному дефекты, которые последние 20 лет исправлялись в существующих криптографических пакетах. Поэтому в любой непонятной ситуации нужно использовать готовые наработки, такие, как OpenSSL, LibreSSL, GPG или OTR. Но что делать, если для вашей конкретной задачи нет готового решения? Например, вы реализуете шифрование на уровне страниц для вашей СУБД, или вам нужно шифровать короткие сообщения, передаваемые с помощью NRF24L01 в самопальном IoT-проекте. В данном случае у вас действительно может не быть большого выбора. Но, по крайней мере, вы можете уменьшить шанс появления существенных дефектов в вашем приложении, используя проверенные временем алгоритмы и режимы шифрования.

Благодаря наличию исключений, язык C++ позволяет разделить основную логику приложения и обработку ошибок, не мешая их в одну кучу. Что есть очень хорошо. Однако теперь по коду нельзя с уверенностью сказать, где может быть прервано его исполнение. Отсюда возникает опасность утечки ресурсов. Проблема эта решается при помощи деструкторов и идиомы RAII. Впрочем, придерживаться этой идиомы становится проблематично при использовании указателей. Особенно при использовании их не как членов класса, а просто как переменных в методах. На наше с вами счастье, в стандартной библиотеке языка есть умные указатели (smart pointers), придуманные именно для этого случая. Поскольку на C++ я пишу не регулярно, то иногда забываю некоторые нюансы использования умных указателей, в связи с чем решил вот набросать небольшую шпаргалку.