16.7. Замечания по отдельным платформам
В этом разделе приведены дополнительные замечания по отдельным платформам, связанные с установкой и подготовкой к работе PostgreSQL. Обязательно изучите ещё инструкции по установке, в частности Раздел 16.2. Также обратитесь к Главе 32, где рассказывается, как прочитать результаты регрессионных тестов.
Если какие-то платформы здесь не упоминаются, значит каких-либо известных особенностей установки в них нет.
16.7.1. AIX
PostgreSQL работает на платформе AIX, однако версии AIX ниже 6.1 использовать не рекомендуется, так как им присущи различные проблемы. Для сборки можно использовать GCC или собственный компилятор IBM xlc.
16.7.1.1. Управление памятью
Иногда управление памятью в AIX может работать несколько странно. В системе может быть свободно несколько гигабайт ОЗУ, но при запуске приложений всё равно возможны ошибки, связанные с адресным пространством или нехваткой памяти. В частности, необычные ошибки могут возникать при загрузке расширений. Например, при выполнении от имени владельца инсталляции PostgreSQL:
=# CREATE EXTENSION plperl; ERROR: could not load library "/opt/dbs/pgsql/lib/plperl.so": A memory address is not in the address space for the process.
(ОШИБКА: не удалось загрузить библиотеку "/opt/dbs/pgsql/lib/plperl.so": Адрес памяти находится не в адресном пространстве процесса.) При выполнении от имени не владельца, а члена группы-владельца инсталляции PostgreSQL:
=# CREATE EXTENSION plperl; ERROR: could not load library "/opt/dbs/pgsql/lib/plperl.so": Bad address
(ОШИБКА: не удалось загрузить библиотеку "/opt/dbs/pgsql/lib/plperl.so": Неверный адрес) Также сообщения о нехватке могут появляться в журнале PostgreSQL при попытке выделить блок памяти размером около 256 МиБ или больше.
Общая причина всех этих проблем связана с битностью и моделью памяти серверного процесса. По умолчанию все исполняемые файлы для AIX собираются как 32-битные, вне зависимости от того, какой тип оборудования или ядра используется. Такие 32-битные процессы ограничиваются общим пространством в 4 ГиБ, разделённым на сегменты по 256 МиБ, по одной из нескольких моделей. По умолчанию в куче можно выделить меньше 256 МиБ, так как она разделяет один сегмент со стеком.
В ситуации с показанным выше примером plperl проверьте umask и разрешения, назначенные для двоичных файлов в вашей инсталляции PostgreSQL. Задействованные в данном примере двоичные файлы были 32-битными и установились с режимом 750 вместо 755. Из-за таких разрешений только владелец или член группы-владельца могли загрузить требуемую библиотеку. Так как она недоступна для чтения всем, загрузчик помещал этот объект в область кучи процесса, а не в сегменты разделяемых библиотек, где он должен находиться.
В «идеале» эту проблему можно решить, если использовать 64-битную сборку PostgreSQL, но это не всегда практично, так как с 32-битным процессором нельзя будет запустить 64-битный код (можно только собрать).
При желании использовать 32-битную версию сервера установите в LDR_CNTRL значение MAXDATA=0x, где 1 <= n <= 8, до запуска PostgreSQL, и попробуйте подобрать подходящее значение и параметры n0000000postgresql.conf. Переменная окружения LDR_CNTRL говорит AIX, что вы хотите, чтобы сервер получил MAXDATA байт для области кучи, в сегментах по 256 МиБ. Подобрав рабочее значение, можно воспользоваться ldedit и модифицировать двоичные файлы, чтобы они использовали такой размер кучи по умолчанию. Тот же эффект можно получить, пересобрав PostgreSQL с указанием configure LDFLAGS="-Wl,-bmaxdata:0x.n0000000"
Для 64-битной сборки определите переменную OBJECT_MODE со значением 64 и передайте configure указания CC="gcc -maix64" и LDFLAGS="-Wl,-bbigtoc". (Для xlc параметры могут быть другими.) Если нужное значение OBJECT_MODE не будет экспортировано, при сборке могут произойти ошибки на стадии компоновки. Когда переменная OBJECT_MODE установлена, она говорит сборочным утилитам AIX, таким как ar, as и ld, какие типы объектов обрабатывать по умолчанию.
По умолчанию система может чрезмерно выделять память в пространстве подкачки. Хотя нам не приходилось с этим сталкиваться, AIX уничтожает процессы при попытке обращения к чрезмерно выделенной памяти, когда её фактически не хватает. Наиболее близкое, что мы наблюдали, была ошибка порождения процесса из-за того, что система решала, что для него не хватает памяти. Как и многие другие компоненты AIX, механизмы распределения пространства подкачки и уничтожения процессов при нехватке памяти можно настроить на уровне системы или процесса, если возникают подобные проблемы.
16.7.2. Cygwin
PostgreSQL можно собрать с применением Cygwin, Linux-подобной среды для Windows, но сейчас этому методу предпочитается обычная сборка в Windows (см. Главу 17), и запускать сервер в среде Cygwin более не рекомендуется.
Выполняя сборку, следуйте процедуре установки в стиле Unix (т. е., ./configure; make; и т. д.) с учётом следующих особенностей Cygwin:
Настройте путь поиска так, чтобы каталог bin в Cygwin стоял перед каталогами утилит Windows. Это поможет избавиться от проблем при компиляции.
Команда
adduserне поддерживается; воспользуйтесь соответствующим средством управления пользователями для Windows NT, 2000 или XP. Либо просто пропустите этот шаг.Команда
suне поддерживается; для эмуляции su в Windows NT, 2000 или XP воспользуйтесь ssh. Либо пропустите этот шаг.OpenSSL не поддерживается.
Запустите
cygserverдля поддержки разделяемой памяти. Для этого введите команду/usr/sbin/cygserver &. Эта программа должна работать всегда при запуске сервера PostgreSQL или инициализации кластера баз данных (initdb). Возможно, вам придётся настроить конфигурациюcygserver(например, увеличитьSEMMNS), чтобы PostgreSQL мог получить требуемые системные ресурсы.Сборка может завершиться ошибкой в некоторых системах, где используется локаль, отличная от C. Чтобы исправить это, выберите локаль C, выполнив
export LANG=C.utf8до сборки, а затем восстановите предыдущее значение после установки PostgreSQL.Параллельные регрессионные тесты (
make check) могут выдавать ложные ошибки тестирования при переполнении очередиlisten(), из-за чего подключения могут не устанавливаться или зависать. Вы можете ограничить число подключений, определив переменную makeMAX_CONNECTIONSтак:make MAX_CONNECTIONS=5 check
(В некоторых системах поддерживается до 10 одновременных подключений).
Сервер PostgreSQL и cygserver можно запустить в виде служб Windows NT. Как это сделать, рассказывается в описании README, включённом в двоичный пакет PostgreSQL для Cygwin. Оно устанавливается в каталог /usr/share/doc/Cygwin.
16.7.3. 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.
16.7.4. MinGW/Собственная сборка Windows
PostgreSQL для Windows можно собрать с использованием MinGW, Unix-подобной среды сборки для операционных систем Microsoft, либо используя набор средств разработки Microsoft Visual C++. При использовании MinGW применяется обычная система сборки, описанная в этой главе; сборка Visual C++ выполняется по-другому, как описано в Главе 17.
PostgreSQL, портированный в Windows, будет работать в 32- или 64-битной версии Windows 2000 или новее. В предыдущих операционных системах нет достаточной инфраструктуры (но там можно использовать Cygwin). 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 есть проблемы с буферизацией.
16.7.4.1. Сбор аварийных дампов в Windows
В случае аварии PostgreSQL в Windows он может сгенерировать минидамп памяти, который помогает выяснить причину аварии, подобно дампам памяти в Unix. Проанализировать эти дампы можно, используя Windows Debugger Tools (Средства отладки Windows) или Visual Studio. Чтобы в Windows получить дамп в случае аварии, создайте подкаталог crashdumps в каталоге данных кластера. Дампы будут записываться в этот каталог с уникальным именем, составленным из идентификатора процесса, давшего сбой, и времени сбоя.
16.7.5. Solaris
PostgreSQL хорошо поддерживается в Solaris. Чем новее операционная система, тем меньше затруднений будет.
16.7.5.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.
16.7.5.2. Процедура configure сообщает о сбое тестовой программы
Если configure сообщает о сбое тестовой программы, это может быть вызвано тем, что при связывании во время выполнения не удаётся найти некоторую библиотеку, вероятно, libz, libreadline или какую-то другую нестандартную, например, libssl. Чтобы указать правильное размещение библиотеки, задайте переменную окружения LDFLAGS в командной строке configure, например так:
configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
За дополнительными сведениями обратитесь к странице man ld.
16.7.5.3. Компиляция для максимальной производительности
Для архитектуры SPARC настоятельно рекомендуется проводить компиляцию с использованием Sun Studio. Добавив флаг -xO5, вы можете получить исполняемый код, который будет работать значительно быстрее. Но не добавляйте никакие флаги, влияющие на вычисления с плавающей точкой или обработку errno (например, -fast).
Если у вас нет причины использовать 64-битные программы в архитектуре SPARC, собирайте 32-битную версию, так как 64-битные операции, а значит и 64-битные программы, выполняются медленнее 32-битных. С другой стороны, 32-битный код для процессоров семейства AMD64 не является «родным», поэтому на таких процессорах значительно медленнее работает 32-битный код.
16.7.5.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 или новее.
16.7. Platform-Specific Notes
This section documents additional platform-specific issues regarding the installation and setup of PostgreSQL. Be sure to read the installation instructions, and in particular Section 16.2 as well. Also, check Chapter 32 regarding the interpretation of regression test results.
Platforms that are not covered here have no known platform-specific installation issues.
16.7.1. AIX
PostgreSQL works on AIX, but AIX versions before about 6.1 have various issues and are not recommended. You can use GCC or the native IBM compiler xlc.
16.7.1.1. Memory Management
AIX can be somewhat peculiar with regards to the way it does memory management. You can have a server with many multiples of gigabytes of RAM free, but still get out of memory or address space errors when running applications. One example is loading of extensions failing with unusual errors. For example, running as the owner of the PostgreSQL installation:
=# CREATE EXTENSION plperl; ERROR: could not load library "/opt/dbs/pgsql/lib/plperl.so": A memory address is not in the address space for the process.
Running as a non-owner in the group possessing the PostgreSQL installation:
=# CREATE EXTENSION plperl; ERROR: could not load library "/opt/dbs/pgsql/lib/plperl.so": Bad address
Another example is out of memory errors in the PostgreSQL server logs, with every memory allocation near or greater than 256 MB failing.
The overall cause of all these problems is the default bittedness and memory model used by the server process. By default, all binaries built on AIX are 32-bit. This does not depend upon hardware type or kernel in use. These 32-bit processes are limited to 4 GB of memory laid out in 256 MB segments using one of a few models. The default allows for less than 256 MB in the heap as it shares a single segment with the stack.
In the case of the plperl example, above, check your umask and the permissions of the binaries in your PostgreSQL installation. The binaries involved in that example were 32-bit and installed as mode 750 instead of 755. Due to the permissions being set in this fashion, only the owner or a member of the possessing group can load the library. Since it isn't world-readable, the loader places the object into the process' heap instead of the shared library segments where it would otherwise be placed.
The “ideal” solution for this is to use a 64-bit build of PostgreSQL, but that is not always practical, because systems with 32-bit processors can build, but not run, 64-bit binaries.
If a 32-bit binary is desired, set LDR_CNTRL to MAXDATA=0x, where 1 <= n <= 8, before starting the PostgreSQL server, and try different values and n0000000postgresql.conf settings to find a configuration that works satisfactorily. This use of LDR_CNTRL tells AIX that you want the server to have MAXDATA bytes set aside for the heap, allocated in 256 MB segments. When you find a workable configuration, ldedit can be used to modify the binaries so that they default to using the desired heap size. PostgreSQL can also be rebuilt, passing configure LDFLAGS="-Wl,-bmaxdata:0x to achieve the same effect. n0000000"
For a 64-bit build, set OBJECT_MODE to 64 and pass CC="gcc -maix64" and LDFLAGS="-Wl,-bbigtoc" to configure. (Options for xlc might differ.) If you omit the export of OBJECT_MODE, your build may fail with linker errors. When OBJECT_MODE is set, it tells AIX's build utilities such as ar, as, and ld what type of objects to default to handling.
By default, overcommit of paging space can happen. While we have not seen this occur, AIX will kill processes when it runs out of memory and the overcommit is accessed. The closest to this that we have seen is fork failing because the system decided that there was not enough memory for another process. Like many other parts of AIX, the paging space allocation method and out-of-memory kill is configurable on a system- or process-wide basis if this becomes a problem.
16.7.2. Cygwin
PostgreSQL can be built using Cygwin, a Linux-like environment for Windows, but that method is inferior to the native Windows build (see Chapter 17) and running a server under Cygwin is no longer recommended.
When building from source, proceed according to the Unix-style installation procedure (i.e., ./configure; make; etc.), noting the following Cygwin-specific differences:
Set your path to use the Cygwin bin directory before the Windows utilities. This will help prevent problems with compilation.
The
addusercommand is not supported; use the appropriate user management application on Windows NT, 2000, or XP. Otherwise, skip this step.The
sucommand is not supported; use ssh to simulate su on Windows NT, 2000, or XP. Otherwise, skip this step.OpenSSL is not supported.
Start
cygserverfor shared memory support. To do this, enter the command/usr/sbin/cygserver &. This program needs to be running anytime you start the PostgreSQL server or initialize a database cluster (initdb). The defaultcygserverconfiguration may need to be changed (e.g., increaseSEMMNS) to prevent PostgreSQL from failing due to a lack of system resources.Building might fail on some systems where a locale other than C is in use. To fix this, set the locale to C by doing
export LANG=C.utf8before building, and then setting it back to the previous setting after you have installed PostgreSQL.The parallel regression tests (
make check) can generate spurious regression test failures due to overflowing thelisten()backlog queue which causes connection refused errors or hangs. You can limit the number of connections using the make variableMAX_CONNECTIONSthus:make MAX_CONNECTIONS=5 check
(On some systems you can have up to about 10 simultaneous connections.)
It is possible to install cygserver and the PostgreSQL server as Windows NT services. For information on how to do this, please refer to the README document included with the PostgreSQL binary package on Cygwin. It is installed in the directory /usr/share/doc/Cygwin.
16.7.3. macOS
To build PostgreSQL from source on macOS, you will need to install Apple's command line developer tools, which can be done by issuing
xcode-select --install
(note that this will pop up a GUI dialog window for confirmation). You may or may not wish to also install Xcode.
On recent macOS releases, it's necessary to embed the “sysroot” path in the include switches used to find some system header files. This results in the outputs of the configure script varying depending on which SDK version was used during configure. That shouldn't pose any problem in simple scenarios, but if you are trying to do something like building an extension on a different machine than the server code was built on, you may need to force use of a different sysroot path. To do that, set PG_SYSROOT, for example
make PG_SYSROOT=/desired/path all
To find out the appropriate path on your machine, run
xcrun --show-sdk-path
Note that building an extension using a different sysroot version than was used to build the core server is not really recommended; in the worst case it could result in hard-to-debug ABI inconsistencies.
You can also select a non-default sysroot path when configuring, by specifying PG_SYSROOT to configure:
./configure ... PG_SYSROOT=/desired/path
This would primarily be useful to cross-compile for some other macOS version. There is no guarantee that the resulting executables will run on the current host.
To suppress the -isysroot options altogether, use
./configure ... PG_SYSROOT=none
(any nonexistent pathname will work). This might be useful if you wish to build with a non-Apple compiler, but beware that that case is not tested or supported by the PostgreSQL developers.
macOS's “System Integrity Protection” (SIP) feature breaks make check, because it prevents passing the needed setting of DYLD_LIBRARY_PATH down to the executables being tested. You can work around that by doing make install before make check. Most PostgreSQL developers just turn off SIP, though.
16.7.4. MinGW/Native Windows
PostgreSQL for Windows can be built using MinGW, a Unix-like build environment for Microsoft operating systems, or using Microsoft's Visual C++ compiler suite. The MinGW build procedure uses the normal build system described in this chapter; the Visual C++ build works completely differently and is described in Chapter 17.
The native Windows port requires a 32 or 64-bit version of Windows 2000 or later. Earlier operating systems do not have sufficient infrastructure (but Cygwin may be used on those). MinGW, the Unix-like build tools, and MSYS, a collection of Unix tools required to run shell scripts like configure, can be downloaded from http://www.mingw.org/. Neither is required to run the resulting binaries; they are needed only for creating the binaries.
To build 64 bit binaries using MinGW, install the 64 bit tool set from https://mingw-w64.org/, put its bin directory in the PATH, and run configure with the --host=x86_64-w64-mingw32 option.
After you have everything installed, it is suggested that you run psql under CMD.EXE, as the MSYS console has buffering issues.
16.7.4.1. Collecting Crash Dumps on Windows
If PostgreSQL on Windows crashes, it has the ability to generate minidumps that can be used to track down the cause for the crash, similar to core dumps on Unix. These dumps can be read using the Windows Debugger Tools or using Visual Studio. To enable the generation of dumps on Windows, create a subdirectory named crashdumps inside the cluster data directory. The dumps will then be written into this directory with a unique name based on the identifier of the crashing process and the current time of the crash.
16.7.5. Solaris
PostgreSQL is well-supported on Solaris. The more up to date your operating system, the fewer issues you will experience.
16.7.5.1. Required Tools
You can build with either GCC or Sun's compiler suite. For better code optimization, Sun's compiler is strongly recommended on the SPARC architecture. If you are using Sun's compiler, be careful not to select /usr/ucb/cc; use /opt/SUNWspro/bin/cc.
You can download Sun Studio from https://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/. Many GNU tools are integrated into Solaris 10, or they are present on the Solaris companion CD. If you need packages for older versions of Solaris, you can find these tools at http://www.sunfreeware.com. If you prefer sources, look at https://www.gnu.org/prep/ftp.
16.7.5.2. configure Complains About a Failed Test Program
If configure complains about a failed test program, this is probably a case of the run-time linker being unable to find some library, probably libz, libreadline or some other non-standard library such as libssl. To point it to the right location, set the LDFLAGS environment variable on the configure command line, e.g.,
configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
See the ld man page for more information.
16.7.5.3. Compiling for Optimal Performance
On the SPARC architecture, Sun Studio is strongly recommended for compilation. Try using the -xO5 optimization flag to generate significantly faster binaries. Do not use any flags that modify behavior of floating-point operations and errno processing (e.g., -fast).
If you do not have a reason to use 64-bit binaries on SPARC, prefer the 32-bit version. The 64-bit operations are slower and 64-bit binaries are slower than the 32-bit variants. On the other hand, 32-bit code on the AMD64 CPU family is not native, so 32-bit code is significantly slower on that CPU family.
16.7.5.4. Using DTrace for Tracing PostgreSQL
Yes, using DTrace is possible. See Section 27.5 for further information.
If you see the linking of the postgres executable abort with an error message like:
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
your DTrace installation is too old to handle probes in static functions. You need Solaris 10u4 or newer to use DTrace.