17.7. Замечания по отдельным платформам #

В этом разделе приведены дополнительные замечания по отдельным платформам, связанные с установкой и подготовкой к работе PostgreSQL. Обязательно изучите ещё инструкции по установке, в частности Раздел 17.1. Также обратитесь к Главе 31, где рассказывается, как прочитать результаты регрессионных тестов.

Если какие-то платформы здесь не упоминаются, значит каких-либо известных особенностей установки в них нет.

17.7.1. Cygwin #

PostgreSQL можно собрать с применением Cygwin, Linux-подобной среды для Windows, но сейчас этому методу предпочитается обычная сборка в Windows, и запускать сервер в среде Cygwin более не рекомендуется.

Выполняя сборку, следуйте процедуре установки в стиле Unix (т. е., ./configure; make; и т. д.) с учётом следующих особенностей Cygwin:

  • Настройте путь поиска так, чтобы каталог bin в Cygwin стоял перед каталогами утилит Windows. Это поможет избавиться от проблем при компиляции.

  • Команда adduser не поддерживается; воспользуйтесь соответствующим средством управления пользователями для Windows. Либо просто пропустите этот шаг.

  • Команда su не поддерживается; для эмуляции su в Windows воспользуйтесь ssh. Либо пропустите этот шаг.

  • OpenSSL не поддерживается.

  • Запустите cygserver для поддержки разделяемой памяти. Для этого введите команду /usr/sbin/cygserver &. Эта программа должна работать всегда при запуске сервера PostgreSQL или инициализации кластера баз данных (initdb). Возможно, вам придётся настроить конфигурацию cygserver (например, увеличить SEMMNS), чтобы PostgreSQL мог получить требуемые системные ресурсы.

  • Сборка может завершиться ошибкой в некоторых системах, где используется локаль, отличная от C. Чтобы исправить это, выберите локаль C, выполнив export LANG=C.utf8 до сборки, а затем восстановите предыдущее значение после установки PostgreSQL.

  • Параллельные регрессионные тесты (make check) могут выдавать ложные ошибки тестирования при переполнении очереди listen(), из-за чего подключения могут не устанавливаться или зависать. Вы можете ограничить число подключений, определив переменную make MAX_CONNECTIONS так:

    make MAX_CONNECTIONS=5 check

    (В некоторых системах поддерживается до 10 одновременных подключений).

Сервер PostgreSQL и cygserver можно запустить в виде служб Windows NT. Как это сделать, рассказывается в описании README, включённом в двоичный пакет PostgreSQL для Cygwin. Оно устанавливается в каталог /usr/share/doc/Cygwin.

17.7.2. macOS #

Чтобы собрать PostgreSQL из исходного кода в macOS, необходимо установить предоставляемые Apple инструменты командной строки для разработки, что можно сделать, выполнив:

xcode-select --install

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

В последних версиях macOS необходимо включать путь «sysroot» во флаги include, позволяющие найти некоторые системные заголовочные файлы. Как результат, вывод скрипта configure может меняться в зависимости от того, какая версия SDK использовалась в процессе configure. Это не должно создавать никаких проблем в простых сценариях, но если вы попытаетесь, например, собрать расширение не на той машине, где был собран серверный код, то может потребоваться явно указать другой путь sysroot. В этом случае установите PG_SYSROOT, например, так:

make PG_SYSROOT=/требуемый/путь all

Чтобы узнать правильный путь на вашей машине, выполните:

xcrun --show-sdk-path

Заметьте, что собирать расширения с версией sysroot, отличной от той, с которой собиралось ядро сервера, не рекомендуется; в худшем случае это приведёт к труднодиагностируемым несогласованностям ABI.

Также при конфигурировании вы можете задать sysroot, отличный от подразумеваемого по умолчанию, передав PG_SYSROOT скрипту configure:

./configure ... PG_SYSROOT=/требуемый/путь

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

Чтобы полностью подавить параметры -isysroot, выполните:

./configure ... PG_SYSROOT=none

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

Функциональность «Защита целостности системы» (System Integrity Protection, SIP) в macOS нарушает работу make check, так как она не позволяет передавать нужное значение DYLD_LIBRARY_PATH тестируемым исполняемым файлам. Обойти эту проблему можно, выполнив make install перед make check. Однако большинство разработчиков PostgreSQL просто отключают SIP.

17.7.3. MinGW #

PostgreSQL для Windows можно собрать с использованием MinGW, Unix-подобной среды сборки для операционных систем Microsoft. При использовании MinGW применяется обычная система сборки, описанная в этой главе.

MinGW, Unix-подобные средства сборки, и MSYS, набор утилит Unix, требуемых для исполнения скриптов типа configure, можно загрузить с сайта http://www.mingw.org/. Эти дополнительные программы нужны только для сборки, для запуска полученных исполняемых файлов они не требуются.

Чтобы собрать 64-битную версию с использованием MinGW, установите набор 64-битных утилит с https://mingw-w64.org/, добавьте путь к его каталогу bin в PATH и запустите configure с параметром --host=x86_64-w64-mingw32.

Когда вы всё установите, запускать psql предлагается из CMD.EXE, так как в консоли MSYS есть проблемы с буферизацией.

17.7.3.1. Сбор аварийных дампов #

В случае аварии PostgreSQL в Windows он может сгенерировать минидамп памяти, который помогает выяснить причину аварии, подобно дампам памяти в Unix. Проанализировать эти дампы можно, используя Windows Debugger Tools (Средства отладки Windows) или Visual Studio. Чтобы в Windows получить дамп в случае аварии, создайте подкаталог crashdumps в каталоге данных кластера. Дампы будут записываться в этот каталог с уникальным именем, составленным из идентификатора процесса, давшего сбой, и времени сбоя.

17.7.4. Solaris #

PostgreSQL хорошо поддерживается в Solaris. Чем новее операционная система, тем меньше затруднений будет.

17.7.4.1. Требуемые инструменты #

Вы можете выполнить сборку с GCC или с набором компиляторов Sun. Для лучшей оптимизации кода на архитектуре SPARC настоятельно рекомендуется использовать компилятор Sun. Если вы решили применить компилятор Sun, не выберите по ошибке /usr/ucb/cc; правильный путь — /opt/SUNWspro/bin/cc.

Sun Studio вы можете загрузить с сайта https://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/. Средства GNU по большей части интегрированы в Solaris 10, либо представлены на сопутствующем CD. Если вам нужны пакеты для старых версий Solaris, вы можете найти их на сайте http://www.sunfreeware.com. Если вы предпочитаете исходный код, обратитесь к https://www.gnu.org/prep/ftp.

17.7.4.2. Процедура configure сообщает о сбое тестовой программы #

Если configure сообщает о сбое тестовой программы, это может быть вызвано тем, что при связывании во время выполнения не удаётся найти некоторую библиотеку, вероятно, libz, libreadline или какую-то другую нестандартную, например, libssl. Чтобы указать правильное размещение библиотеки, задайте переменную окружения LDFLAGS в командной строке configure, например так:

configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"

За дополнительными сведениями обратитесь к странице man ld.

17.7.4.3. Компиляция для максимальной производительности #

Для архитектуры SPARC настоятельно рекомендуется проводить компиляцию с использованием Sun Studio. Добавив флаг -xO5, вы можете получить исполняемый код, который будет работать значительно быстрее. Но не добавляйте никакие флаги, влияющие на вычисления с плавающей точкой или обработку errno (например, -fast).

Если у вас нет причины использовать 64-битные программы в архитектуре SPARC, собирайте 32-битную версию, так как 64-битные операции, а значит и 64-битные программы, выполняются медленнее 32-битных. С другой стороны, 32-битный код для процессоров семейства AMD64 не является «родным», поэтому на таких процессорах значительно медленнее работает 32-битный код.

17.7.4.4. Применение DTrace для трассировки PostgreSQL #

Да, вы можете использовать DTrace. За дополнительными сведениями обратитесь к Разделу 27.5.

Если компоновка исполняемого файла postgres прерывается с таким сообщением об ошибке:

Undefined                       first referenced
 symbol                             in file
AbortTransaction                    utils/probes.o
CommitTransaction                   utils/probes.o
ld: fatal: Symbol referencing errors. No output written to postgres
collect2: ld returned 1 exit status
make: *** [postgres] Error 1

Это означает, что ваша инсталляция DTrace слишком стара и неспособна работать с пробами в статических функциях. Для использования DTrace нужна версия Solaris 10u4 или новее.

17.7.5. Visual Studio #

Для большинства пользователей рекомендуется просто загрузить дистрибутив для Windows в виде инсталляционного пакета с графическим интерфейсом с сайта PostgreSQL: https://www.postgresql.org/download/. Компиляция из исходного кода описана только для разработчиков сервера PostgreSQL или его расширений.

PostgreSQL для Windows с Visual Studio можно собрать с помощью Meson, как описано в Разделе 17.4. PostgreSQL, портированный в Windows, будет работать в 32- или 64-битной версии Windows 10 или новее.

«Родные» сборки psql не поддерживают редактирование командной строки. Однако сборка в Cygwin это поддерживает, так что следует выбрать её, когда необходимо интерактивно использовать psql в Windows.

PostgreSQL может быть собран с помощью компилятора Visual C++ от Microsoft. Этот компилятор есть в пакетах Visual Studio, Visual Studio Express и в некоторых версиях Microsoft Windows SDK. Если у вас ещё не установлена среда Visual Studio, проще всего будет использовать компиляторы из Visual Studio 2022 или из Windows SDK 10, которые Microsoft распространяет бесплатно.

С применением инструментария Microsoft Compiler возможна и 32-, и 64-битная сборка. 32-битную сборку PostgreSQL можно произвести с использованием Visual Studio 2015Visual Studio 2022, а также отдельных выпусков Windows SDK версии 10 и новее. Для 64-битных сборок также можно использовать Microsoft Windows SDK версии 10 и новее или Visual Studio 2015 и новее.

Если с вашим инструментарием для разработки не поставляется поддерживаемая версия Microsoft Windows SDK, рекомендуется установить последнюю версию SDK (в настоящее время 10), которую можно загрузить с https://www.microsoft.com/download.

Устанавливая SDK, вы всегда должны выбирать для установки пункт Windows Headers and Libraries (Заголовочные файлы и библиотеки Windows). Если вы установили Windows SDK, включая Visual C++ Compilers, Visual Studio для сборки вам не нужна. Обратите внимание, что с версии 8.0a в SDK для Windows не включается полное окружение для сборки в командной строке.

17.7.5.1. Требования #

Для сборки PostgreSQL в Windows требуются следующие дополнительные продукты:

ActiveState Perl

ActiveState Perl требуется для запуска скриптов, управляющих сборкой. Perl из MinGW или Cygwin работать не будет. ActiveState Perl также должен находиться по пути в PATH. Готовый двоичный пакет можно загрузить с https://www.activestate.com (Обратите внимание, что требуется версия 5.14 или выше, при этом достаточно бесплатного стандартного дистрибутива (Standard Distribution).)

Bison и Flex

Требуются Bison версии 2.3 или выше и Flex версии 2.5.35 или выше.

И Bison, и Flex входят в комплект утилит msys, который можно загрузить с http://www.mingw.org/wiki/MSYS в качестве компонента набора MinGW.

Вам потребуется добавить каталог, содержащий flex.exe и bison.exe, в путь, задаваемый переменной PATH. В случае с MinGW, это будет подкаталог \msys\1.0\bin в каталоге вашей инсталляции MinGW.

Примечание

Bison, поставляемый в составе GnuWin32, может работать некорректно, когда он установлен в каталог с именем, содержащим пробелы, например, C:\Program Files\GnuWin32 (целевой каталог по умолчанию в англоязычной системе). В таком случае, возможно, стоит установить его в C:\GnuWin32 или задать в переменной окружения PATH короткий путь NTFS к GnuWin32 (например, C:\PROGRA~1\GnuWin32).

Следующее дополнительное ПО не требуется для базовой сборки, но требуется для сборки полного пакета.

ActiveState Tcl

Требуется для компиляции PL/Tcl (Обратите внимание, что требуется версия 8.4 или выше, при этом достаточно бесплатного стандартного дистрибутива (Standard Distribution)).

Diff

Diff требуется для запуска регрессионных тестов, его можно загрузить с http://gnuwin32.sourceforge.net.

Gettext

Gettext требуется для сборки с поддержкой NLS, его можно загрузить с http://gnuwin32.sourceforge.net. Обратите внимание, что для сборки потребуются и исполняемые файлы, и зависимости, и файлы для разработки.

MIT Kerberos

Требуется для поддержки проверки подлинности GSSAPI. MIT Kerberos можно загрузить с https://web.mit.edu/Kerberos/dist/index.html.

libxml2 и libxslt

Требуется для поддержки XML. Двоичный пакет можно загрузить с https://zlatkovic.com/pub/libxml, а исходный код с http://xmlsoft.org. Учтите, что для libxml2 требуется iconv, который можно загрузить там же.

LZ4

Требуется для поддержки метода сжатия LZ4. Двоичные файлы и исходный код можно загрузить с https://github.com/lz4/lz4/releases.

Zstandard

Требуется для поддержки метода сжатия Zstandard. Двоичные файлы и исходный код можно загрузить с https://github.com/facebook/zstd/releases.

OpenSSL

Требуется для поддержки SSL. Двоичные пакеты можно загрузить с https://slproweb.com/products/Win32OpenSSL.html, а исходный код с https://www.openssl.org.

ossp-uuid

Требуется для поддержки UUID-OSSP (только для contrib). Исходный код можно загрузить с http://www.ossp.org/pkg/lib/uuid/.

Python

Требуется для сборки PL/Python. Двоичные пакеты можно загрузить с https://www.python.org.

zlib

Требуется для поддержки сжатия в pg_dump и pg_restore. Двоичные пакеты можно загрузить с https://www.zlib.net.

17.7.5.2. Специальные замечания для 64-битной Windows #

PostgreSQL для архитектуры x64 можно собрать только в 64-битной Windows.

Совместная сборка 32- и 64-битных версий в одном дереве не поддерживается. Система сборки автоматически определит, в каком окружении (32- или 64-битном) она запущена, и соберёт соответствующий вариант PostgreSQL. Поэтому сборку важно запускать в командной оболочке, предоставляющей нужное окружение.

Для использования на стороне сервера сторонних библиотек, таких как Python или OpenSSL, эти библиотеки также должны быть 64-битными. 64-битный сервер не поддерживает загрузку 32-битных библиотек. Некоторые библиотеки сторонних разработчиков, предназначенные для PostgreSQL, могут быть доступны только в 32-битных версиях и в таком случае их нельзя будет использовать с 64-битной версией PostgreSQL.

17.7.5.3. Сбор аварийных дампов #

В случае аварии PostgreSQL в Windows он может сгенерировать минидамп памяти, который помогает выяснить причину аварии, подобно дампам памяти в Unix. Проанализировать эти дампы можно, используя Windows Debugger Tools (Средства отладки Windows) или Visual Studio. Чтобы в Windows получить дамп в случае аварии, создайте подкаталог crashdumps в каталоге данных кластера. Дампы будут записываться в этот каталог с уникальным именем, составленным из идентификатора процесса, давшего сбой, и времени сбоя.