無料スクリプト配布のPHP.TO   PHPの実用的なtips PHPマニュアル MySQLマニュアル Apacheマニュアル PostgreSQLマニュアル マニュアル検索    

15.7. プラットフォーム特有の覚書

本節はPostgreSQLのインストールと設定に関する追加のプラットフォーム固有の問題について説明します。 インストール手順、特に 項15.2 を注意して読んでください。 またリグレッション試験結果の解釈については 第30章 を確認してください。

ここで触れられていないプラットフォームは、インストールに関してプラットフォーム特有の問題がありません。

15.7.1. AIX

AIX上でPostgreSQLは動作しますが、適切にインストールをやり遂げるのは挑戦でもあります。AIXバージョン4.3.3から6.1はサポートされていると考えられます。GCCまたは在来のIBMコンパイラ xlc が使用できます。一般的に、最新のAIXとPostgreSQLバージョンを使用することが手助けになります。どのバージョンのAIXが動くと知られているかについての最新情報をビルドファームで見てください。

サポートされるAIXバージョンに対する最低限推奨される修正レベルを示します。

AIX 4.3.3

保守レベル 11 + ML11 バンドル以降

AIX 5.1

保守レベル 9 + ML9 バンドル以降

AIX 5.2

技術レベル 10 サービスパック 3

AIX 5.3

技術レベル 7

AIX 6.1

基本レベル

使用している修正レベルをチェックするには、AIX 4.3.3 から AIX 5.2 ML 7 までは oslevel -r 、またはそれ以降のバージョンでは oslevel -s を使用します。

もし、 /usr/local にインストール済のreadlineやライブラリがある場合は、次の configure フラグを加えて下さい。 --with-includes=/usr/local/include --with-libraries=/usr/local/lib

15.7.1.1. GCCの問題

AIX 5.3でGCCを使ってPostgreSQLがコンパイルし実行するためには幾つかの問題点があります。

特にパッケージ版を使用している場合、3.3.2以降のバージョンのGCCの使用が望まれるかもしれません。4.0.1ではうまくいきます。より早期のバージョンによる諸問題は、GCC自体の問題というよりもIBMがGCCをパッケージした方法に関連があるように見えます。従い、GCCを自身でコンパイルしている場合は、早期のバージョンのGCCを使用しても成功するかもしれません。

15.7.1.2. Unixドメインソケット破損

AIX 5.3には sockaddr_storage が十分大きく定義されていないという問題があります。 バージョン5.3でIBMはUnixドメインソケットのアドレス構造体である sockaddr_un のサイズを増やしましたが、対応する sockaddr_storage のサイズを増やしませんでした。 この結果、PostgreSQLでUnixドメインソケットを使用しようとすると、libpqでデータ構造体がオーバーフローするようになります。 Unixドメインソケットを除くTCP/IP接続の動作は正常です。 これはリグレッションテストの動作を妨害します。

この問題はIBMに報告済みでバグ報告PMR29657として記録されています。 メンテナンスレベル5300-03以降に更新していれば、この修正が含まれています。 すぐに解決させたければ、 /usr/include/sys/socket.h 内で _SS_MAXSIZE を1025に変更してください。 どちらの場合でも、ヘッダファイルを修正した後でPostgreSQLを再コンパイルしてください。

15.7.1.3. インターネットアドレス問題

PostgreSQLは listen_addresses pg_hba.conf 、その他の中のIPアドレスを構文解釈するのにシステムの getaddrinfo 関数に頼ります。旧バージョンのAIXにはこの関数にさまざまなバグがあります。これら設定に関係した問題に遭遇した場合、上記に示されている適切な修正レベルへ更新することが問題解決になります。

あるユーザの報告です。

PostgreSQLバージョン8.1をAIX 5.3で実装している時、統計情報コレクタが "不思議なことに" 正常に起動しないという問題が周期的に起こりました。これは、IPv6の実装における想定外の動作という結果で出現します。そのため、AIX5.3上ではPostgreSQLとIPv6が一緒にはうまく動作しないように見えました。

以下のいずれかの対応でこの問題が "解決できます"

  • localhostに対するIPv6アドレスを削除します。

    (as root)
    # ifconfig lo0 inet6 ::1/0 delete

  • ネットサービスからIPv6を削除します。AIXの /etc/netsvc.conf ファイルは大まかに言ってSolaris/Linuxの /etc/nsswitch.conf と同等です。AIXのデフォルトは、以下のようになっています。

    hosts=local,bind

    これを次で置き換えます。

    hosts=local4,bind4

    そうすると、IPv6アドレスの検索が解除されます。

警告

これは、実際には未熟なIPv6サポートに関連する問題の回避策です。AIX5.3のリリースから、IPv6サポートが目に見えて改善されています。この回避策はAIX5.3上で動きはしますが、この問題に対しての良い解決方法ではありません。AIX6.1ではIPv6サポートがさらに改善されたため、この対策は不必要になっただけでなく、問題を引き起こすことが報告されています。

15.7.1.4. メモリ管理

AIXはメモリ管理手法の観点から見ると多少独特です。 ギガバイト単位のRAMが空いているサーバがあっても、アプリケーションを実行している時にメモリ不足やアドレス空間エラーが発生することがあります。 こうした例の1つが、見慣れないエラーによる 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.

PostgreSQLインストレーションの処理グループ内の所有者以外として実行してみます。

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

他の実例は、PostgreSQLサーバログ中のメモリ不足エラーで、256 MB以上もしくはその近辺で全てのメモリ割り当てが失敗します。

これら問題のすべての総合原因は、サーバプロセスで使用されるデフォルトのビット割当とメモリモデルです。 デフォルトでは、AIXで構築されたすべてのバイナリは32ビットです。 これは使用中のハードウェアの種類やカーネルに依存しません。 これらの32ビットプロセスは、数個のモデルの1つを使用して256メガバイトのセグメントで割りつけられた4ギガバイトメモリに制限されます。 デフォルトでは、スタックで1つのセグメントとして共有されるものとしてヒープ内の256メガバイト未満の領域が許されます。

上記、 createlang 例の場合において、PostgreSQLインストレーションにおけるバイナリのumaskとパーミッションをチェックしてください。例に関与したバイナリは32-ビットであり、755ではなく750モードでインストールされました。このような形式で設定されたパーミッションのため、所有者もしくはグループ所有のメンバーのみライブラリを読み込めます。それは誰もが読み取り可能ではないため、ローダは、そうでない場合に配置される共有ライブラリセグメントにではなく、オブジェクトをプロセスのヒープに配置します。

これに対しての "理想的な" 解決策はPostgreSQLの64-ビットビルドを使うことですが、32-ビットプロセッサのシステムでは64-ビットバイナリをビルドできますが実行できないので、常に実務的ではありません。

32-ビットバイナリを要求する場合、PostgreSQLサーバを起動する前に LDR_CNTRL MAXDATA=0x n 0000000 に設定します。ここで、1 <= n <= 8です。そして異なる値と postgresql.conf 設定で満足に稼動する構成を見つけ出します。 この LDR_CNTRL 使用するとAIXに対して、サーバがヒープにかかわらず、256 MBセグメントに割り当てられた MAXDATA バイトセットを持つようにさせたい意図を表明します。稼動する構成を見つけたとき、意図したヒープ容量をデフォルトで使用するように ldedit を使用してバイナリを変更することができます。同じ効果を得るため、PostgreSQLは configure LDFLAGS="-Wl,-bmaxdata:0x n 0000000" を渡して再構築することもできます。

64-ビット構築に対し、 OBJECT_MODE を64に設定し、 configure CC="gcc -maix64" LDFLAGS="-Wl,-bbigtoc" を渡します。( xlc に対するオプションは異なるかもしれません。) OBJECT_MODE のexportを省略すると、構築はリンカエラーで失敗することがあります。 OBJECT_MODE が設定された場合、 ar as 、および ld のようなAIXの構築ユーティリティにどの種類のオブジェクトがデフォルトで対応されるのかを伝えます。

デフォルトで、ページングスペースのオーバーコミットが起こることがあります。これが起こることを経験したことはありませんが、AIXはメモリを使い切って、オーバーコミットがアクセスされたときにプロセスをkillします。システムが別のプロセスに対する十分なメモリがないことを判断したためにフォークが失敗するという、これとよく似たことは経験したことがあります。多くの他のAIX部分のように、ページングスペース割り当て方式とメモリ不足によるプロセス停止は、これが問題となるのであれば、システム全体またはプロセス全体を基準として設定可能です。

参照とリソース

" Large Program Support ", AIX Documentation: General Programming Concepts: Writing and Debugging Programs .

" Program Address Space Overview ", AIX Documentation: General Programming Concepts: Writing and Debugging Programs .

" Performance Overview of the Virtual Memory Manager (VMM) ", AIX Documentation: Performance Management Guide .

" Page Space Allocation ", AIX Documentation: Performance Management Guide .

" Paging-space thresholds tuning ", AIX Documentation: Performance Management Guide .

15.7.2. Cygwin

Windowsに対するLinux的環境である、Cygwinを使ってPostgreSQLを構築することが可能です。しかし、この手法はWindowsネイティブビルド( 第16章 を参照)には及ばないので、もはや推奨されません。

ソースから構築する場合、以下のCygwin特有の差異に注意し、通常のインストール手順に従って進めます(つまり、 ./configure; make ; など)。

  • Windowsユーティリティの前に使用するCygwinのbinディレクトリのパスを設定します。コンパイルにおける問題を回避する助けになります。

  • GNU make コマンドは gmake ではなく、 make と呼ばれます。

  • adduser コマンドはサポートされていません。Windows NT、2000、またはXP上の適切なユーザ管理アプリケーションを使用してください。そうでなければ、この手順を飛ばします。

  • su コマンドはサポートされていません。Windows NT、2000、またはXP上でsuをシミュレートするため、sshを使用します。そうでなければ、この手順を飛ばします。

  • OpenSSLはサポートされていません。

  • 共有メモリサポートのために cygserver を開始します。行うためには、コマンド /usr/sbin/cygserver & を入力します。このプログラムはPostgreSQLサーバを起動するとき、または( initdb で)データベースクラスタを初期化するときときはいつでも必要です。システム資源が欠けていることによるPostgreSQLの失敗を避けるため、デフォルトの cygserver 設定は(例えば SEMMNS を増加させることで)変更される必要があります。

  • いくつかのシステムでは、Cロケール以外を使っている場合に構築が失敗するかもしれません。 これに対処するためには、構築前に export LANG=C.utf8 を実施してロケールをCに設定し、PostgreSQLのインストール後に以前の設定に戻してください。

  • 並行リグレッションテスト( make check )は、接続拒絶エラーやハングアップを引き起こす listen() バックログキューのオーバーフローにより、誤ったリグレッションテストの失敗を生成する可能性があります。make 変数 MAX_CONNECTIONS を使用して、最大接続数を制限できます。つまり次のようにします。

    make MAX_CONNECTIONS=5 check

    (いくつかのシステムでは、同時接続を10まで広げられます。)

Windows NTサービスとして cygserver とPostgreSQLサーバをインストールすることができます。これを実現する方法は、CygwinのPostgreSQLバイナリパッケージに含まれる README 文書を参照してください。それは /usr/share/doc/Cygwin ディレクトリにインストールされます。

15.7.3. HP-UX

PostgreSQL 7.3以上は、適切なシステムパッチレベルと構築ツールが与えられているとして、HP-UX 10.Xまたは11.Xが稼動するSeries 700/800 PA-RISCコンピュータで動作します。少なくとも1つの開発者が定期的にHP-UX10.20で試験を行っており、HP-UX11.00と11.11上へのインストールが成功していることの報告を受けています。

PostgreSQLのソース配布物は別として、GNU make(HPのmakeは通りません)と、GCCもしくはHPのANSI Cコンパイラの全部いずれかが必要です。配布物tarボールではなくGitソースから構築を行う時は、Flex(GNU lex)とBison(GNU yacc)も必要です。同時に、正確に最新のHPパッチが当たっていることの確認を推奨します。HP-UX 11.11上で64ビット構築を行うのであれば最小限、PHSS_30966 (11.11)またはその後継パッチが必要です。さもないと、 initdb がハングアップします。以下を参考にしてください。

PHSS_30966  s700_800 ld(1) and linker tools cumulative patch

一般原則として、HPのCコンパイラを使用する場合、libcとld/dldパッチとコンパイラパッチが最新版でなければなりません。それらの最新パッチの無償コピーについては、 http://itrc.hp.com および ftp://us-ffs.external.hp.com/ のHPサポートサイトを見てください。

PA-RISC 2.0マシン上でGCCを使用して64-ビットバイナリを構築したい場合、GCC 64-ビット版を使用しなければなりません。HP-UX PA-RISCとItanium用のバイナリは http://www.hp.com/go/gcc から入手できます。同時にbinutilsも入手しインストールすることを忘れないでください。

PA-RISC 2.0装置上での構築で、PA-RISC 1.1装置で稼動するコンパイル済みのバイナリが必要な場合、 CFLAGS +DAportable を指定する必要があります。

HP-UX Itaniumマシン上で構築するのであれば、依存するパッチまたはその後継のパッチが当たった最新のHP ANSI Cコンパイラが必要です。以下です。

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

HPのCコンパイラとGCCの2つが存在するとき、 configure 実行時に明示的に使用するコンパイラを指定したい場合、HPのCコンパイラでは、

./configure CC=cc

GCCの場合は、

./configure CC=gcc

のようにします。この設定を省略すると、選択できる場合にはconfigureは gcc を選びます。

デフォルトのインストール対象配置場所は /usr/local/pgsql で、 /opt のような場所に変更したい場合もあります。そのような時は、 configure --prefix スイッチを使用します。

リグレッションテストにおいて、幾何試験で下位ビット桁の差異があるかもしれません。これはどのコンパイラを使用しているか、使用している数学ライブラリのバージョンは何かに依存し、変化します。その他のエラーは原因を疑ってください。

15.7.4. IRIX

PostgreSQLは無事に、MIPSProコンパイラのバージョン 7.30、7.3.1.2m、7.3、および7.4.4mが有効なIRIX 6.5.5m、6.5.12、6.5.13、および6.5.26が稼動するMIPS r8000、r10000(ip25とip27の双方)、およびr12000(ip35)プロセッサでの実行が報告されています。

MIPSProの完全なANSI C コンパイラが必要です。GCCで構築しようとするとき問題があります。それは、ある種類の構造を返す関数の使用に関連した、知られているGCCのバグ(バージョン3.0時点で修正されていない)です。バグは inet_ntoa inet_lnaof inet_netof inet_makeaddr 、および semctl のような関数に影響します。libgccでのそれらの関数にコードのリンクを強制して修正ができそうですが、未だ検証されていません。

MIPSProコンパイラのバージョン7.4.1mは不正なコードを生成することが知られています。症状はデータベースを開始する際、 "invalid primary checkpoint record(無効な主チェックポイントレコード)" となることです。バージョン7.4.4mは大丈夫ですが、その中間にあるバージョンは不明確です。

次のようなコンパイル問題があるかもしれません。

cc-1020 cc: ERROR File = pqcomm.c, Line = 427
  The identifier "TCP_NODELAY" is undefined.

                if (setsockopt(port->sock, IPPROTO_TCP, TCP_NODELAY,

幾つかのバージョンはTCP定義を sys/xti.h に含みますので、 src/backend/libpq/pqcomm.c src/interfaces/libpq/fe-connect.c #include <sys/xti.h> を加える必要があります。これに遭遇した場合、報告してもらえると適切な修正を開発できます。

リグレッションテストの中で、これは使用しているFPUに依存し、幾何試験で下位ビット桁の差異があるかもしれません。その他のエラーは原因を疑ってください。

15.7.5. MinGW/ネイティブWindows

Windows用PostgreSQLは、Microsoftオペレーティングシステム用のUnixに似た構築環境であるMinGW、またはMicrosoftの Visual C++ コンパイラ一式を使って構築できます。MinGW版の構築は本章で記述されている通常の構築システムを使用します。Visual C++構築は、 第16章 で記述するようにまったく異なった動作をします。それは完全にネイティブな構築で、MinGWのような追加ソフトウェアを使用しません。既製のインストーラがPostgreSQLのメインウェブサイトから入手できます。

ネイティブに移植されたWindows版ではWindows 2000以降の32ビットまたは64ビット版が必要です。これより前のオペレーティングシステムには充分な構造基盤がありません(ただし、Cygwinはそれら上で使える可能性があります)。Unixに似た構築ツールであるMinGWと、 configure のようなシェルスクリプトを実行するために必要なUnixツール群であるMSYSは、 http://www.mingw.org/ からダウンロード可能です。作成されたバイナリの実行にはいずれも必要ありません。バイナリの作成のためのみ必要です。

MinGWを使って64ビット版バイナリをビルドするためには、 http://mingw-w64.sourceforge.net/ から64ビット用のツールを入手してインストールし、 PATH にあるbinディレクトリへそれらを入れ、そして --host=x86_64-w64-mingw オプション付きで configure を実施します。

MSYSコンソールはバッファリングに問題があるので、すべてをインストールした後に CMD.EXE 下で psql を実行することを推奨します。

15.7.5.1. Windows上でのクラッシュダンプの収集

もしWindows上のPostgreSQLがクラッシュした場合、Unixにおけるコアダンプと似た、クラッシュの原因を追跡するために使用できる minidumps を生成することができます。 このダンプは Windows Debugger Tools Visual Studio を使うことで解析できます。Windowsにてダンプを生成できるように、 crashdumps という名前のサブディレクトリをデータベースクラスタディレクトリの中に作成します。 ダンプは、クラッシュ時の現在時間と原因となったプロセスの識別子を元にした一意な名前としてこのディレクトリの中に生成されます。

15.7.6. SCO OpenServer と SCO UnixWare

PostgreSQLはSCO UnixWare 7 と SCO OpenServer 5上で構築できます。OpenServerについて、OpenServer Development Kit または the 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以降では、UDK CDの中にGCCコンパイラとGNU Makeが含まれます。

15.7.6.2. GNU Make

GNU Makeプログラムを使用する必要があり、それはSkunkware CDの中にあります。デフォルトでは /usr/local/bin/make としてインストールします。SCO make プログラムとの混乱を避けるため、GNU make gmake と名称変更した方が便利かもしれません。

UnixWare 7.1.3およびそれ以上で、GNU MakeプログラムはUDK CDのOSTK部分で、 /usr/gnu/bin/gmake にあります。

15.7.6.3. Readline

ReadlineライブラリはSkunkware CDにあります。しかし、UnixWare 7.1 Skunkware CDにはありません。もしUnixWare 7.0.0 または 7.0.1 Skunkware CDを所有していれば、そこからインストールできます。そうでない場合、 http://www.sco.com/skunkware/ を試してください。

デフォルトでReadlineは /usr/local/lib /usr/local/include にインストールされます。しかし、PostgreSQL の configure プログラムは援助無しにそこにあることを見つけません。Readlineをインストールしたなら、 configure で以下のオプションを使ってください。

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

15.7.6.4. OpenServer上でUDKを使用

もしOpenServer上で新規のUniversal Development Kit (UDK) コンパイラを使用しているのであれば、以下のようにUDKライブラリの場所を指定する必要があります。

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

Putting these together with the Readline options from above:

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

15.7.6.5. PostgreSQLマニュアルページを読む

デフォルトで、PostgreSQLマニュアルページは /usr/local/pgsql/man にインストールされます。デフォルトで、UnixWareはマニュアルページとしてその場所を見ません。マニュアルページを読めるようにするには、以下の例のように、 /etc/default/man MANPATH 変数を変更します。

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

OpenServerについてマニュアルページが使用できるようにするため幾つかの追加研究が注ぎ込まれる必要があります。その理由はマニュアルシステムは他のプラットフォームとは多少異なるからです。現在、PostgreSQLはそれら全てをインストールしません。

15.7.6.6. 7.1.1b機能追加でのC99問題

7.1.1b機能追加を含む、OpenUNIX 8.0.0(UnixWare 7.1.2)と共にリリースされたものより早期のコンパイラでは、 CFLAGS または CC 環境変数で -Xb を指定する必要があります。この兆候は、インライン関数を参照する tuplesort.c をコンパイルするエラーです。明らかに、これは7.1.2(8.0.0)とそれ以降のコンパイラで変更されています。

15.7.6.7. UnixWare上のスレッド

スレッド処理のためには すべての libpqを使用するプログラムにて -Kpthread を使用する 必要があります 。libpqは pthread_* 呼び出しを使用しますが、 -Kpthread / -Kthread フラグを伴わないと有効ではありません。

15.7.7. Solaris

PostgreSQLはSolaris上でとても良くサポートされています。オペレーティングシステムが更新されればされる程、問題点の遭遇は少なくなります。以下に詳細を示します。

15.7.7.1. 必要なツール

GCCもしくはSunのコンパイラ一式により構築できます。より良いコード最適化のため、SunのコンパイラはSPARC構造上においては、強く推奨されます。GCC 2.95.1を使用する場合に問題があったと報告を受けています。GCC 2.95.3以降を勧めます。Sunのコンパイラを使用するのであれば、 /usr/ucb/cc を選択せず、 /opt/SUNWspro/bin/cc を使用するように注意してください。

http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/ からSun Studioをダウンロードできます。 数多くのGNUツールがSolaris 10に統合、もしくはSolaris companion CDの中にあります。 Solarisのより古いバージョンに対するパッケージを好むのであれば、それらのツールは http://www.sunfreeware.com にあります。 ソースの方が良いという方は http://www.gnu.org/order/ftp.html を参照してください。

15.7.7.2. OpenSSLでの問題点

OpenSSLサポート付きでPostgreSQLを構築するとき、以下に示したファイルでコンパイルエラーを受け取ることがあります。

  • 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のような非標準のライブラリを見つけ出せないことによります。それを正しい場所に指し示すため、 configure コマンドラインで LDFLAGS 環境変数を以下のように設定します。

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

より詳細な情報は ld マニュアルページを参照ください。

15.7.7.4. 時折クラッシュする64-ビット構築

Solaris 7以前の64bit版のlibcには不具合のある vsnprintf ルーチンがあり、それはPostgreSQLのエラーコアダンプに繋がります。既知の最も単純な回避策は、ライブラリのコピーではなく、自身の vsnprintf バージョンを使うように仕向けることです。これを行うためには、 configure を実行した後、 configure で生成されたファイルを編集します。 つまり、 src/Makefile.global の以下の行

LIBOBJS =

を次のように変更します。

LIBOBJS = snprintf.o

(この変数に既に他のファイルが列挙されているかもしれません。その順序は関係ありません。)その後、通常通りに構築してください。

15.7.7.5. 最適性能を得るためのコンパイル

SPARCアーキテクチャにおけるコンパイルでは、Sun Studioを強く推奨します。特筆するような速さのバイナリを生成するため、 -xO5 最適化フラグを使用してみてください。浮動小数点演算と、( -fast のような) errno 演算を修正するようなフラグはすべて使ってはいけません。それらのフラグは、例えばdate/time演算において、PostgreSQLの標準ではない動作をさせることがあります。

SPARCで64ビットバイナリを使用する理由がないのであれば、32ビット版を選択してください。64ビット操作はより遅く、64ビットバイナリは32ビット版より遅いのです。一方で、AMD64 CPUファミリ上の32ビットコードはネイティブではありません。これが、このCPUファミリで32ビットコードが非常に低速な理由です

15.7.7.6. PostgreSQLをトレースするためのDTrace使用

そのとおりです。DTraceを使うことができます。より詳細な情報は 項27.4 を参照してください。 より多くの情報が https://blogs.oracle.com/robertlor/entry/user_level_dtrace_probes_in 文書にあります。

以下のようなエラーメッセージで postgres 実行形式のリンクが中断することを体験した場合、そのDTraceインストールが静的関数におけるプローブを扱うには古すぎると言うことです。Solaris 10u4もしくはそれより新しいものが必要です。

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
gmake: *** [postgres] Error 1


powered by SEO.CUG.NET