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

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

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

15.7.1. AIX

Postgres Pro работает в AIX, но установить его правильно может быть непростой задачей. Поддерживаемыми считаются версии AIX с 4.3.3 до 6.1. Для сборки вы можете применить GCC или собственный компилятор IBM xlc. Вообще говоря, полезно использовать последние версии AIX и Postgres Pro. Получить актуальную информацию о версиях AIX, работа в которых проверена на данный момент, можно на сайте фермы сборки.

Минимальные рекомендуемые уровни исправлений для поддерживаемых версий AIX:

AIX 4.3.3

Эксплуатационный уровень (ML) 11 + пакет исправлений после ML11

AIX 5.1

Эксплуатационный уровень (ML) 9 + пакет исправлений после ML9

AIX 5.2

Технологический уровень (TL) 10, Пакет обновлений (SP) 3

AIX 5.3

Технологический уровень (TL) 7

AIX 6.1

Базовый уровень

Чтобы проверить ваш текущий уровень исправлений, выполните oslevel -r в AIX версии с 4.3.3 по 5.2 ML 7, либо oslevel -s в более поздних версиях.

Если Readline или libz у вас установлены не в /usr/local, передайте configure следующие ключи в дополнение к вашим: --with-includes=/usr/local/include --with-libraries=/usr/local/lib.

15.7.1.1. Особенности использования GCC

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

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

15.7.1.2. Неработающие Unix-сокеты

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

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

15.7.1.3. Проблемы с сетевыми адресами

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

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

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

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

  • Удалите адрес IPv6 для localhost:

    (от имени root)
    # ifconfig lo0 inet6 ::1/0 delete
    
  • Удалите IPv6 из сетевых сервисов. Файл /etc/netsvc.conf в AIX примерно соответствует файлу /etc/nsswitch.conf в Solaris/Linux. По умолчанию в AIX он выглядит так:

    hosts=local,bind

    Чтобы отключить поиск адресов IPv6, замените его содержимое следующим:

    hosts=local4,bind4

Предупреждение

К этим временным решениям приходилось прибегать из-за проблем, связанных с сырой реализацией IPv6, которая заметно улучшилась в последующих выпусках AIX 5.3. Эти решения работали в AIX версии 5.3, но они конечно далеки от идеальных. Кроме того, сообщалось, что они не только не требуются, но и приводят к другим проблемам в AIX 6.1, где поддержка IPv6 стала более зрелой.

15.7.1.4. Управление памятью

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

-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": Адрес памяти находится не в адресном пространстве процесса.) При запуске от имени не владельца, а члена группы-владельца инсталляции Postgres Pro:

-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": Неверный адрес) Также сообщения о нехватке памяти могут появляться в журнале Postgres Pro при попытке выделить блок памяти размером около 256 МиБ или больше.

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

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

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

При желании использовать 32-битную версию сервера установите в LDR_CNTRL значение MAXDATA=0xn0000000, где 1 <= n <= 8, до запуска Postgres Pro, и попробуйте подобрать подходящее значение и параметры postgresql.conf. Переменная окружения LDR_CNTRL говорит AIX, что вы хотите, чтобы сервер получил MAXDATA байт для области кучи, в сегментах по 256 МиБ. Подобрав рабочее значение, можно воспользоваться ldedit и модифицировать двоичные файлы, чтобы они использовали такой размер кучи по умолчанию. Тот же эффект можно получить, пересобрав Postgres Pro с указанием 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, механизмы распределения пространства подкачки и уничтожения процессов при нехватке памяти можно настроить на уровне системы или процесса, если возникают подобные проблемы.

Ссылки и ресурсы

«Large Program Support». Документация AIX: Общие концепции программирования: Написание и отладка программ.

«Program Address Space Overview». Документация AIX: Общие концепции программирования: Написание и отладка программ.

«Performance Overview of the Virtual Memory Manager (VMM)». Документация AIX: Руководство по управлению производительностью.

«Page Space Allocation». Документация AIX: Руководство по управлению производительностью.

«Paging-space thresholds tuning». Документация AIX: Руководство по управлению производительностью.

15.7.2. Cygwin

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

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

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

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

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

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

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

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

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

    make MAX_CONNECTIONS=5 check

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

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

15.7.3. HP-UX

PostgreSQL 7.3+ и Postgres Pro должен работать на машинах Series 700/800 PA-RISC под управлением HP-UX 10.X или 11.X, с подходящими уровнями системных исправлений и средствами сборки. Как минимум один разработчик регулярно тестирует сборку в HP-UX 10.20, и мы получали сообщения об успешных установках в HP-UX 11.00 и 11.11.

Помимо пакета исходного кода Postgres Pro, вам потребуется GNU make (HP make не подойдёт) и GCC или полный компилятор ANSI C от HP. Если вы намерены выполнить сборку не из дистрибутивного пакета исходного кода, а из Git, вам также потребуется Flex (GNU lex) и Bison (GNU yacc). Мы также рекомендуем убедиться, что у вас установлены довольно свежие исправления HP. Для сборки 64-битного кода в HP-UX 11.11 вам потребуется PHSS_30966 (11.11) или более новое исправление, без него initdb может зависать. Как правило, для сборки нужно иметь текущие исправления libc и ld/dld, а также компилятора (если вы используете компилятор HP). Получить эти исправления бесплатно можно на сайтах поддержки HP http://itrc.hp.com и ftp://us-ffs.external.hp.com/.

Если вы проводите сборку на машине PA-RISC 2.0 и хотите получить 64-битный исполняемый код, вы должны использовать 64-битную версию GCC. Скомпилированный GCC для HP-UX PA-RISC и Itanium доступен по адресу http://www.hp.com/go/gcc. Не забудьте также загрузить и установить binutils.

Если вы проводите сборку на машине PA-RISC 2.0 и хотите, чтобы скомпилированный код запускался на машинах PA-RISC 1.1, также потребуется указать +DAportable в CFLAGS.

Если вы проводите сборку на машине HP-UX Itanium, вам потребуется последний компилятор ANSI C от HP с соответствующим исправлением или более новыми:


PHSS_30848  s700_800 HP C Compiler (A.05.57)
PHSS_30849  s700_800 u2comp/be/plugin library Patch

Если вы используете компилятор HP C и GCC, может потребоваться явно выбрать предпочитаемый компилятор при запуске configure:

./configure CC=cc

для использования компилятора C от HP, либо

./configure CC=gcc

для выбора GCC. При отсутствии явного указания configure выберет gcc, если есть такая возможность.

По умолчанию целевой каталог установки — /usr/local/pgsql, но вы, возможно, захотите его изменить на другой, внутри /opt. В этом случае передайте его configure с ключом --prefix.

В регрессионных тестах возможны отклонения при геометрических проверках, в наименее значащих цифрах, в зависимости от применяемого компилятора и математической библиотеки. Любые другие ошибки заслуживают внимания.

15.7.4. macOS

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

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

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

xcodebuild -version -sdk macosx Path

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

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

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

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

15.7.5. MinGW/Собственная сборка Windows

Postgres Pro для Windows можно собрать с использованием MinGW, Unix-подобной среды сборки для операционных систем Microsoft, либо используя набор средств разработки Microsoft Visual C++. При использовании MinGW применяется обычная система сборки, описанная в этой главе; сборка с Visual C++ выполняется по-другому, как описано в Главе 16. Это полностью естественная сборка для Windows, для которой не требуется дополнительное ПО вроде MinGW. Готовый инсталлятор для Windows можно найти на сайте Postgres Pro.

PostgreSQL, портированный в Windows, будет работать в 32- или 64-битной версии Windows 2000 или новее. В предыдущих операционных системах нет достаточной инфраструктуры (но там можно использовать Cygwin). MinGW, Unix-подобные средства сборки, и MSYS, набор утилит Unix, требуемых для исполнения скриптов типа configure, можно загрузить с сайта http://www.mingw.org/. Эти дополнительные программы нужны только для сборки, для запуска полученных исполняемых файлов они не требуются.

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

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

15.7.5.1. Сбор аварийных дампов в Windows

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

15.7.6. SCO OpenServer и SCO UnixWare

Postgres Pro можно собрать в SCO UnixWare 7 и SCO OpenServer 5. В OpenServer для сборки можно использовать либо Инструменты разработки OpenServer (OpenServer Development Kit), либо Универсальные средства разработки (Universal Development Kit). Возможно, при этом потребуется выполнить дополнительные действия, как описано ниже.

15.7.6.1. Skunkware

Вы должны найти свою копию 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.

15.7.6.2. GNU Make

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

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

15.7.6.3. Readline

Библиотека 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 для Postgres Pro не сможет найти её там без дополнительной помощи. Поэтому, если вы установили Readline, передайте configure следующие параметры:

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

15.7.6.4. Использование UDK в OpenServer

Если вы используете новый компилятор из Универсальных средств разработки (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"

15.7.6.5. Получение справки man по Postgres Pro

По умолчанию страницы man для Postgres Pro устанавливаются в /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 работает немного не так, как в других. В настоящее время Postgres Pro просто не устанавливает справочные страницы в ней.

15.7.6.6. Проблемы C99 с функциональным дополнением 7.1.1b

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

15.7.6.7. Многопоточность в UnixWare

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

15.7.7. Solaris

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

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

Вы можете выполнить сборку с 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.

15.7.7.2. Проблемы с OpenSSL

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

  • src/backend/libpq/crypt.c

  • src/backend/libpq/password.c

  • src/interfaces/libpq/fe-auth.c

  • src/interfaces/libpq/fe-connect.c

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

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

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

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

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

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

15.7.7.4. Периодические сбои 64-битной сборки

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

LIBOBJS =

на такую

LIBOBJS = snprintf.o

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

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

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

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

15.7.7.6. Применение DTrace для трассировки Postgres Pro

Да, вы можете использовать DTrace. За дополнительными сведениями обратитесь к Разделу 27.4. Другую полезную информацию можно найти в этой статье: 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 или новее.