В AIX 5.3 наблюдались проблемы с компиляцией и запуском PostgreSQL с использованием GCC.

Для успешной сборки вам потребуется GCC версии новее 3.3.2, особенно, если вы используете версию из системного пакета. Мы добивались успеха с 4.0.1. Проблемы с предыдущими версиями, судя по всему, были связаны больше с тем, как IBM упаковала GCC, а не собственно с GCC, поэтому если вы скомпилируете GCC самостоятельно, положительный исход возможен и с ранней версией GCC.

В AIX 5.3 была проблема с размером структуры sockaddr_storage. В версии 5.3 IBM увеличила размер sockaddr_un, структуры адреса для Unix-сокетов, но не увеличила соответственно размер sockaddr_storage. В итоге при попытке PostgreSQL использовать Unix-сокеты происходило переполнение этой структуры в libpq. Подключение через TCP/IP устанавливается корректно, а через Unix-сокеты — нет, и в результате регрессионные тесты не проходят.

Об этой проблеме было сообщено IBM, она зафиксирована в отчёте об ошибке PMR29657. Если вы обновите систему до эксплуатационного уровня 5300-03 или новее, она получит соответствующее исправление. В качестве временного решения можно присвоить _SS_MAXSIZE значение 1025 в /usr/include/sys/socket.h. В любом случае после исправления этого заголовочного файла перекомпилируйте PostgreSQL.

PostgreSQL пользуется системной функцией getaddrinfo для разбора IP-адресов, указанных в параметре listen_addresses, файле pg_hba.conf и т. д. В старых версиях AIX эта функция работала некорректно. Если вы столкнулись с проблемами в этой области, обновление до уровня исправлений AIX, обозначенного выше, должно решить их.

Один пользователь сообщает:

Используя PostgreSQL версии 8.1 в AIX 5.3, мы периодически сталкивались с тем, что сборщик статистики «загадочным образом» не запускается. Кажется, это результат незапланированного поведения реализации IPv6. Похоже, что PostgreSQL и IPv6 не дружат в AIX 5.3.

Для «решения» проблемы можно выполнить одно из следующих действий.

Иногда управление памятью в AIX может работать несколько странно. В системе может быть свободно несколько гигабайт ОЗУ, но при запуске приложений всё равно возможны ошибки, связанные с адресным пространством или нехваткой памяти. Например, необычную ошибку может выдать команда createlang. При запуске от имени владельца инсталляции PostgreSQL:

-bash-3.00$ createlang plperl template1
createlang: language installation failed: ERROR:  could not load library "/opt/dbs/pgsql748/lib/plperl.so": A memory address is not in the address space for the process.

(createlang: установить язык не удалось: ОШИБКА: не удалось загрузить библиотеку "/opt/dbs/pgsql748/lib/plperl.so": Адрес памяти находится не в адресном пространстве процесса.) При запуске от имени не владельца, а члена группы-владельца инсталляции PostgreSQL:

-bash-3.00$ createlang plperl template1
createlang: language installation failed: ERROR:  could not load library "/opt/dbs/pgsql748/lib/plperl.so": Bad address

(createlang: установить язык не удалось: ОШИБКА: не удалось загрузить библиотеку "/opt/dbs/pgsql748/lib/plperl.so": Неверный адрес) Также сообщения о нехватке памяти могут появляться в журнале PostgreSQL при попытке выделить блок памяти размером около 256 МиБ или больше.

Общая причина всех этих проблем связана с битностью и моделью памяти серверного процесса. По умолчанию все исполняемые файлы для AIX собираются как 32-битные, вне зависимости от того, какой тип оборудования или ядра используется. Такие 32-битные процессы ограничиваются общим пространством в 4 ГиБ, разделённым на сегменты по 256 МиБ, по одной из нескольких моделей. По умолчанию в куче можно выделить меньше 256 МиБ, так как она разделяет один сегмент со стеком.

В ситуации с показанным выше примером createlang, проверьте umask и разрешения, назначенные для двоичных файлов в вашей инсталляции PostgreSQL. Задействованные в данном примере двоичные файлы были 32-битными и установились с режимом 750 вместо 755. Из-за таких разрешений только владелец или член группы-владельца могли загрузить требуемую библиотеку. Так как она недоступна для чтения всеми, загрузчик помещал этот объект в область кучи процесса, а не в сегменты разделяемых библиотек, где он должен находиться.

В «идеале» эту проблему можно решить, если использовать 64-битную сборку PostgreSQL, но это не всегда практично, так как с 32-битным процессором нельзя будет запустить 64-битный код (можно только собрать).

При желании использовать 32-битную версию сервера установите в LDR_CNTRL значение MAXDATA=0xn0000000, где 1 <= n <= 8, до запуска PostgreSQL, и попробуйте подобрать подходящее значение и параметры postgresql.conf. Переменная окружения LDR_CNTRL говорит AIX, что вы хотите, чтобы сервер получил MAXDATA байт для области кучи, в сегментах по 256 МиБ. Подобрав рабочее значение, можно воспользоваться ldedit и модифицировать двоичные файлы, чтобы они использовали такой размер кучи по умолчанию. Тот же эффект можно получить, пересобрав PostgreSQL с указанием configure LDFLAGS="-Wl,-bmaxdata:0xn0000000".

Для 64-битной сборки определите переменную OBJECT_MODE со значением 64 и передайте configure указания CC="gcc -maix64" и LDFLAGS="-Wl,-bbigtoc". (Для xlc параметры могут быть другими.) Если нужное значение OBJECT_MODE не будет экспортировано, при сборке могут произойти ошибки на стадии компоновки. Когда переменная OBJECT_MODE установлена, она говорит сборочным утилитам AIX, таким как ar, as и ld, какие типы объектов обрабатывать по умолчанию.

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

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

Вы должны найти свою копию SCO Skunkware CD. Skunkware CD поставлялся с UnixWare 7 и текущими версиями OpenServer 5. В набор Skunkware входят готовые к установке версии многих популярных программ, доступных в Интернете. В частности, в него входят gzip, gunzip, GNU Make, Flex и Bison. Для UnixWare 7.1 этот CD называется «Open License Software Supplement» (Дополнительное ПО с открытыми лицензиями). Если у вас нет такого CD, это ПО можно найти на сайте http://www.sco.com/skunkware/.

Версии Skunkware для UnixWare и OpenServer различаются. Убедитесь, что вы устанавливаете правильную версию для вашей ОС, но учтите следующие замечания.

В UnixWare 7.1.3 и новее компилятор GCC поставляется на UDK CD, вместе с GNU Make.

Вам потребуется программа GNU Make, которая находится на Skunkware CD. По умолчанию она устанавливается в /usr/local/bin/make.

В UnixWare 7.1.3 и новее программа GNU Make включена в раздел OSTK диска UDK и устанавливается в /usr/gnu/bin/gmake.

Библиотека Readline поставляется на Skunkware CD, но она не включена в Skunkware CD для UnixWare 7.1. Если у вас есть Skunkware CD для UnixWare 7.0.0 или 7.0.1, вы можете установить её с этого диска. В противном случае обратитесь к http://www.sco.com/skunkware/.

По умолчанию Readline устанавливается в /usr/local/lib и /usr/local/include. Однако configure для PostgreSQL не сможет найти её там без дополнительной помощи. Поэтому, если вы установили Readline, передайте configure следующие параметры:

./configure --with-libraries=/usr/local/lib --with-includes=/usr/local/include

Если вы используете новый компилятор из Универсальных средств разработки (UDK, Universal Development Kit) в OpenServer, вам потребуется задать размещение библиотек UDK:

./configure --with-libraries=/udk/usr/lib --with-includes=/udk/usr/include

Совместите эти параметры с заданными выше для Readline:

./configure --with-libraries="/udk/usr/lib /usr/local/lib" --with-includes="/udk/usr/include /usr/local/include"

По умолчанию страницы man для PostgreSQL устанавливаются в /usr/local/pgsql/share/man. Но UnixWare по умолчанию не ищет там эти страницы. Чтобы вы могли обращаться к ним, потребуется изменить переменную MANPATH в /etc/default/man, например так:

MANPATH=/usr/lib/scohelp/%L/man:/usr/dt/man:/usr/man:/usr/share/man:scohelp:/usr/local/man:/usr/local/pgsql/share/man

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

Для компиляторов, более ранних, чем выпущенный с OpenUNIX 8.0.0 (UnixWare 7.1.2), в том числе с функциональным дополнением 7.1.1b, может потребоваться указать -Xb в переменной окружения CC или CFLAGS. Признаком этой проблемы будет ошибка при компиляции tuplesort.c в коде, ссылающемся на встроенные функции. Судя по всему, соответствующее исправление включено в компилятор версии 7.1.2(8.0.0) и новее.

Для использования многопоточности вы должны добавлять указание -Kpthread при компиляции всех программ на базе libpq. Библиотека libpq вызывает функции pthread_*, которые доступны только при компиляции с флагом -Kpthread/-Kthread.

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

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

Собирая PostgreSQL с поддержкой OpenSSL, вы можете получить ошибки компиляции в следующих файлах:

Это вызвано конфликтом имён между стандартным /usr/include/crypt.h и заголовочными файлами в составе OpenSSL.

Эту проблему можно решить, обновив инсталляцию OpenSSL до версии 0.9.6a. Solaris 9 и новее уже включает обновлённую версию OpenSSL.

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

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

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

В Solaris 7 и старее 64-битная версия libc содержала бракованную функцию vsnprintf, которая могла вызывать непредсказуемые сбои PostgreSQL. Самое простое известное решение — сделать, чтобы PostgreSQL использовал собственную версию vsnprintf вместо библиотечной версии. Для этого, выполнив configure, отредактируйте полученный в результате configure файл. В src/Makefile.global поменяйте строку

LIBOBJS =

на такую

LIBOBJS = snprintf.o

(В этой переменной уже также могут быть перечислены и другие файлы.) Затем продолжите сборку как обычно.

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

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

Да, вы можете использовать DTrace. За дополнительными сведениями обратитесь к Разделу 28.5. Другую полезную информацию можно найти в этой статье: https://blogs.oracle.com/robertlor/entry/user_level_dtrace_probes_in.

Если компоновка исполняемого файла 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 слишком стара и неспособна работать с пробами в статических функциях. В этом случае вам нужна версия Solaris 10u4 или новее.