This section documents additional platform-specific issues regarding the installation and setup of PostgreSQL. Be sure to read the installation instructions, and in particular <xref linkend="install-requirements"/> as well. Also, check <xref linkend="regress"/> regarding the interpretation of regression test results. 本節はPostgreSQLのインストールと設定に関する追加のプラットフォーム固有の問題について説明します。 インストール手順、特に17.1を注意して読んでください。 またリグレッションテスト結果の解釈については第33章を確認してください。
Platforms that are not covered here have no known platform-specific installation issues. ここで触れられていないプラットフォームは、インストールに関してプラットフォーム特有の問題がありません。
You can use GCC or the native IBM compiler <command>xlc</command>
to build <productname>PostgreSQL</productname>
on <productname>AIX</productname>.
GCCまたは在来のIBMコンパイラxlcを使用して、AIX上でPostgreSQLを構築できます。
<productname>AIX</productname> versions before 7.1 are no longer tested nor supported by the <productname>PostgreSQL</productname> community. AIX 7.1より前のバージョンは、PostgreSQLコミュニティではテストもサポートもされていません。
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: AIXはメモリ管理手法の観点から見ると多少独特です。 ギガバイト単位のRAMが空いているサーバがあっても、アプリケーションを実行している時にメモリ不足やアドレス空間エラーが発生することがあります。 こうした例の1つが、見慣れないエラーによる拡張のロードの失敗です。 例えば、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.
Running as a non-owner in the group possessing the PostgreSQL installation: PostgreSQLインストレーションの処理グループ内の所有者以外として実行してみます。
=# 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. 他の実例は、PostgreSQLサーバログ中のメモリ不足エラーで、256 MB以上もしくはその近辺で全てのメモリ割り当てが失敗します。
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. これら問題のすべての総合原因は、サーバプロセスで使用されるデフォルトのビット割当とメモリモデルです。 デフォルトでは、AIXで構築されたすべてのバイナリは32ビットです。 これは使用中のハードウェアの種類やカーネルに依存しません。 これらの32ビットプロセスは、数個のモデルの1つを使用して256メガバイトのセグメントで割りつけられた4ギガバイトメモリに制限されます。 デフォルトでは、スタックで1つのセグメントとして共有されるものとしてヒープ内の256メガバイト未満の領域が許されます。
In the case of the <literal>plperl</literal> 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.
上記、plperlの例の場合において、PostgreSQLインストレーションにおけるバイナリのumaskとパーミッションをチェックしてください。
例に関与したバイナリは32-ビットであり、755ではなく750モードでインストールされました。
このような形式で設定されたパーミッションのため、所有者もしくはグループ所有のメンバーのみライブラリを読み込めます。
それは誰もが読み取り可能ではないため、ローダは、そうでない場合に配置される共有ライブラリセグメントにではなく、オブジェクトをプロセスのヒープに配置します。
The <quote>ideal</quote> 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. これに対しての「理想的な」解決策はPostgreSQLの64-ビットビルドを使うことですが、32-ビットプロセッサのシステムでは64-ビットバイナリをビルドできますが実行できないので、常に実務的ではありません。
If a 32-bit binary is desired, set <symbol>LDR_CNTRL</symbol> to
<literal>MAXDATA=0x<replaceable>n</replaceable>0000000</literal>,
where 1 <= n <= 8, before starting the PostgreSQL server,
and try different values and <filename>postgresql.conf</filename>
settings to find a configuration that works satisfactorily. This
use of <symbol>LDR_CNTRL</symbol> tells AIX that you want the
server to have <symbol>MAXDATA</symbol> bytes set aside for the
heap, allocated in 256 MB segments. When you find a workable
configuration,
<command>ldedit</command> can be used to modify the binaries so
that they default to using the desired heap size. PostgreSQL can
also be rebuilt, passing <literal>configure
LDFLAGS="-Wl,-bmaxdata:0x<replaceable>n</replaceable>0000000"</literal>
to achieve the same effect.
32-ビットバイナリを要求する場合、PostgreSQLサーバを起動する前にLDR_CNTRLをMAXDATA=0xに設定します。ここで、1 <= n <= 8です。そして異なる値とn0000000postgresql.conf設定で満足に稼働する構成を見つけ出します。
このようにLDR_CNTRLを使用すると、AIXに対してサーバがヒープにかかわらず、256 MBセグメントに割り当てられたMAXDATAバイトセットを持つようにさせたい意図を表明します。
稼働する構成を見つけたとき、意図したヒープ容量をデフォルトで使用するようにldeditを使用してバイナリを変更できます。
同じ効果を得るため、configure LDFLAGS="-Wl,-bmaxdata:0xを渡してPostgreSQLを再構築することもできます。
n0000000"
For a 64-bit build, set <envar>OBJECT_MODE</envar> to 64 and
pass <literal>CC="gcc -maix64"</literal>
and <literal>LDFLAGS="-Wl,-bbigtoc"</literal>
to <command>configure</command>. (Options for
<command>xlc</command> might differ.) If you omit the export of
<envar>OBJECT_MODE</envar>, your build may fail with linker errors. When
<envar>OBJECT_MODE</envar> is set, it tells AIX's build utilities
such as <command>ar</command>, <command>as</command>, and <command>ld</command> what
type of objects to default to handling.
64-ビット構築に対し、OBJECT_MODEを64に設定し、configureにCC="gcc -maix64"とLDFLAGS="-Wl,-bbigtoc"を渡します。
（xlcに対するオプションは異なるかもしれません。）
OBJECT_MODEのexportを省略すると、構築はリンカエラーで失敗することがあります。
OBJECT_MODEが設定された場合、ar、as、およびldのようなAIXの構築ユーティリティにどの種類のオブジェクトがデフォルトで対応されるのかを伝えます。
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. デフォルトで、ページングスペースのオーバーコミットが起こることがあります。 これが起こることを経験したことはありませんが、AIXはメモリを使い切って、オーバーコミットがアクセスされたときにプロセスをkillします。 システムが別のプロセスに対する十分なメモリがないことを判断したためにフォークが失敗するという、これとよく似たことは経験したことがあります。 多くの他のAIX部分のように、ページングスペース割り当て方式とメモリ不足によるプロセス停止は、これが問題となるのであれば、システム全体またはプロセス全体を基準として設定可能です。
PostgreSQL can be built using Cygwin, a Linux-like environment for Windows, but that method is inferior to the native Windows build <phrase condition="standalone-ignore">(see <xref linkend="install-windows"/>)</phrase> and running a server under Cygwin is no longer recommended. Windowsに対するLinux的環境である、Cygwinを使ってPostgreSQLを構築できます。 しかし、この手法はWindowsネイティブビルド（第18章を参照）には及ばないので、もはや推奨されません。
When building from source, proceed according to the Unix-style
installation procedure (i.e., <literal>./configure;
make</literal>; etc.), noting the following Cygwin-specific
differences:
ソースから構築する場合、以下のCygwin特有の差異に注意し、Unix形式のインストール手順に従って進めます（つまり、./configure;make; など）。
Set your path to use the Cygwin bin directory before the Windows utilities. This will help prevent problems with compilation. Windowsユーティリティの前に使用するCygwinのbinディレクトリのパスを設定します。 コンパイルにおける問題を回避する助けになります。
The <command>adduser</command> command is not supported; use
the appropriate user management application on Windows.
Otherwise, skip this step.
《マッチ度[73.426573]》adduserコマンドはサポートされていません。Windows NT、2000、またはXP上の適切なユーザ管理アプリケーションを使用してください。
そうでなければ、この手順を飛ばします。
《機械翻訳》adduserコマンドはサポートされていません。
Windowsで適切なユーザ管理アプリケーションを使用してください。
それ以外の場合は、この手順を省略してください。
The <command>su</command> command is not supported; use ssh to
simulate su on Windows. Otherwise, skip this step.
《マッチ度[67.256637]》suコマンドはサポートされていません。Windows NT、2000、またはXP上でsuをシミュレートするため、sshを使用します。
そうでなければ、この手順を飛ばします。
《機械翻訳》suコマンドはサポートされていません。
Windowsでsuをシミュレートするにはsshを使用してください。
そうでなければ、このステップを省略してください。
<productname>OpenSSL</productname> is not supported. OpenSSLはサポートされていません。
Start <command>cygserver</command> for shared memory support.
To do this, enter the command <literal>/usr/sbin/cygserver
&</literal>. This program needs to be running anytime you
start the PostgreSQL server or initialize a database cluster
(<command>initdb</command>). The
default <command>cygserver</command> configuration may need to
be changed (e.g., increase <symbol>SEMMNS</symbol>) to prevent
PostgreSQL from failing due to a lack of system resources.
共有メモリサポートのためにcygserverを開始します。
これを行うためには、コマンド/usr/sbin/cygserver&を入力します。
このプログラムはPostgreSQLサーバを起動するとき、または（initdbで）データベースクラスタを初期化するときはいつでも必要です。
システム資源が欠けていることによるPostgreSQLの失敗を避けるため、デフォルトのcygserver設定を（例えばSEMMNSを増やすなど）変更する必要があるかもしれません。
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
<command>export LANG=C.utf8</command> before building, and then
setting it back to the previous setting after you have installed
PostgreSQL.
いくつかのシステムでは、Cロケール以外を使っている場合に構築が失敗するかもしれません。
これに対処するためには、構築前にexport LANG=C.utf8を実施してロケールをCに設定し、PostgreSQLのインストール後に以前の設定に戻してください。
The parallel regression tests (<literal>make check</literal>)
can generate spurious regression test failures due to
overflowing the <function>listen()</function> backlog queue
which causes connection refused errors or hangs. You can limit
the number of connections using the make
variable <varname>MAX_CONNECTIONS</varname> thus:
並行リグレッションテスト（make check）は、接続拒絶エラーやハングアップを引き起こすlisten()バックログキューのオーバーフローにより、誤ったリグレッションテストの失敗を生成する可能性があります。
make 変数MAX_CONNECTIONSを使用して、最大接続数を制限できます。つまり次のようにします。
make MAX_CONNECTIONS=5 check
(On some systems you can have up to about 10 simultaneous connections.) （いくつかのシステムでは、同時接続を10まで広げられます。）
It is possible to install <command>cygserver</command> and the
PostgreSQL server as Windows NT services. For information on how
to do this, please refer to the <filename>README</filename>
document included with the PostgreSQL binary package on Cygwin.
It is installed in the
directory <filename>/usr/share/doc/Cygwin</filename>.
Windows NTサービスとしてcygserverとPostgreSQLサーバをインストールできます。
これを実現する方法は、CygwinのPostgreSQLバイナリパッケージに含まれるREADME文書を参照してください。
それは/usr/share/doc/Cygwinディレクトリにインストールされます。
To build <productname>PostgreSQL</productname> from source on <productname>macOS</productname>, you will need to install Apple's command line developer tools, which can be done by issuing PostgreSQLをmacOSでソースから構築するには、Appleのコマンドライン開発ツールをインストールすることが必要で、次のようにすれば行えます
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. （確認のためGUIダイアログウィンドウが現れることに注意してください）。 Xcodeもインストールして構いませんし、しなくても構いません。
On recent <productname>macOS</productname> releases, it's necessary to
embed the <quote>sysroot</quote> path in the include switches used to
find some system header files. This results in the outputs of
the <application>configure</application> script varying depending on
which SDK version was used during <application>configure</application>.
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 <varname>PG_SYSROOT</varname>,
for example
最近のmacOSのリリースでは、システムヘッダファイルを見つけるために使われるインクルードスイッチに「sysroot」のパスを埋め込むことが必要です。
これにより、configureでどのSDKのバージョンが使われたかに依存して、configureスクリプトの出力が変わることになります。
これは簡単なシナリオでは問題を引き起こさないでしょうが、サーバのコードが構築されたのとは異なるマシンで拡張を構築するなどのようなことを試みているのだとしたら、異なるsysrootのパスを利用するように強制することが必要です。
そうするには、PG_SYSROOTを設定してください。例えば以下のようにです。
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. コアサーバを構築するのに使われたのとは異なるsysrootのバージョンを使って拡張を構築することは、実のところ勧められないことに注意してください。最悪の場合、デバッグの難しいABIの不一致を招くかもしれません。
You can also select a non-default sysroot path when configuring, by
specifying <varname>PG_SYSROOT</varname>
to <application>configure</application>:
configureにPG_SYSROOTを指定することで、configureの時にデフォルトでないsysrootのパスを選ぶこともできます。
./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. これは主に他のバージョンのmacOS用にクロスコンパイルするのに有用でしょう。 結果として作られる実行ファイルが現在のホストで動作する保証はありません。
To suppress the <option>-isysroot</option> options altogether, use
-isysrootオプションを完全に抑制するには、以下のようにします(存在しないパス名であればどのようなものであっても動作します)。
./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. これはApple製でないコンパイラで構築するのに有用かもしれませんが、この状況はPostgreSQLの開発者がテストもサポートもしていないことに注意してください。
<productname>macOS</productname>'s <quote>System Integrity
Protection</quote> (SIP) feature breaks <literal>make check</literal>,
because it prevents passing the needed setting
of <literal>DYLD_LIBRARY_PATH</literal> down to the executables being
tested. You can work around that by doing <literal>make
install</literal> before <literal>make check</literal>.
Most PostgreSQL developers just turn off SIP, though.
macOSの「System Integrity Protection」 (SIP)機能は、DYLD_LIBRARY_PATHの必要な設定をテスト対象の実行ファイルに渡すのを妨げますので、make checkを壊します。
make checkの前にmake installとすることで回避できます。
ですが、PostgreSQLの開発者はほとんど単にSIPをオフにしています。
PostgreSQL for Windows can be built using MinGW, a Unix-like build environment for Microsoft operating systems, or using Microsoft's <productname>Visual C++</productname> 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 <xref linkend="install-windows"/>. Windows用PostgreSQLは、Microsoftオペレーティングシステム用のUnixに似た構築環境であるMinGW、またはMicrosoftのVisual C++コンパイラ一式を使って構築できます。 MinGW版の構築は本章で記述されている通常の構築システムを使用します。Visual C++構築は、第18章で記述するようにまったく異なった動作をします。
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 <command>configure</command>, can be downloaded
from <ulink url="http://www.mingw.org/"></ulink>. Neither is
required to run the resulting binaries; they are needed only for
creating the binaries.
ネイティブに移植されたWindows版ではWindows 2000以降の32ビットまたは64ビット版が必要です。
これより前のオペレーティングシステムには十分な構造基盤がありません（ただし、Cygwinはそれら上で使える可能性があります）。
Unixに似た構築ツールであるMinGWと、configureのようなシェルスクリプトを実行するために必要なUnixツール群であるMSYSは、http://www.mingw.org/からダウンロード可能です。
作成されたバイナリの実行にはいずれも必要ありません。バイナリの作成のためのみ必要です。
To build 64 bit binaries using MinGW, install the 64 bit tool set
from <ulink url="https://mingw-w64.org/"></ulink>, put its bin
directory in the <envar>PATH</envar>, and run
<command>configure</command> with the
<command>--host=x86_64-w64-mingw32</command> option.
MinGWを使って64ビット版バイナリをビルドするためには、https://mingw-w64.org/から64ビット用のツールを入手してインストールし、PATHにあるbinディレクトリへそれらを入れ、そして--host=x86_64-w64-mingw32オプション付きでconfigureを実施します。
After you have everything installed, it is suggested that you
run <application>psql</application>
under <command>CMD.EXE</command>, as the MSYS console has
buffering issues.
MSYSコンソールはバッファリングに問題があるので、すべてをインストールした後にCMD.EXE下でpsqlを実行することを推奨します。
If PostgreSQL on Windows crashes, it has the ability to generate
<productname>minidumps</productname> 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 <productname>Windows Debugger Tools</productname> or using
<productname>Visual Studio</productname>. To enable the generation of dumps
on Windows, create a subdirectory named <filename>crashdumps</filename>
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.
もしWindows上のPostgreSQLがクラッシュした場合、Unixにおけるコアダンプと似た、クラッシュの原因を追跡するために使用できるminidumpsを生成できます。
このダンプはWindows Debugger ToolsやVisual Studioを使うことで解析できます。Windowsにてダンプを生成できるように、crashdumpsという名前のサブディレクトリをデータベースクラスタディレクトリの中に作成します。
ダンプは、クラッシュ時の現在時間と原因となったプロセスの識別子を元にした一意な名前としてこのディレクトリの中に生成されます。
PostgreSQL is well-supported on Solaris. The more up to date your operating system, the fewer issues you will experience. PostgreSQLはSolaris上でとても良くサポートされています。 オペレーティングシステムが更新されればされる程、問題点の遭遇は少なくなります。
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
<filename>/usr/ucb/cc</filename>;
use <filename>/opt/SUNWspro/bin/cc</filename>.
GCCもしくはSunのコンパイラ一式により構築できます。
より良いコード最適化のため、SPARCアーキテクチャではSunのコンパイラを強く推奨します。
Sunのコンパイラを使用するのであれば、/usr/ucb/ccを選択せず、/opt/SUNWspro/bin/ccを使用するように注意してください。
You can download Sun Studio from <ulink url="https://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/"></ulink>. 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 <ulink url="http://www.sunfreeware.com"></ulink>. If you prefer sources, look at <ulink url="https://www.gnu.org/prep/ftp"></ulink>. https://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/からSun Studioをダウンロードできます。 数多くのGNUツールがSolaris 10に統合、もしくはSolaris companion CDの中にあります。 Solarisのより古いバージョンに対するパッケージが必要であれば、それらのツールはhttp://www.sunfreeware.comにあります。 ソースの方が良いという方はhttps://www.gnu.org/prep/ftpを参照してください。
If <command>configure</command> 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 <envar>LDFLAGS</envar> environment
variable on the <command>configure</command> command line, e.g.,
もしconfigureが失敗したテストプログラムについてエラーを出す場合、おそらく実行時のリンカがlibz、libreadline、またはlibsslのような非標準のライブラリを見つけ出せないことによります。
それを正しい場所に指し示すため、configureコマンドラインでLDFLAGS環境変数を例えば以下のように設定します。
configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
See the <citerefentry><refentrytitle>ld</refentrytitle><manvolnum>1</manvolnum></citerefentry> man page for more information. より詳細な情報はldマニュアルページを参照してください。
On the SPARC architecture, Sun Studio is strongly recommended for
compilation. Try using the <option>-xO5</option> optimization
flag to generate significantly faster binaries. Do not use any
flags that modify behavior of floating-point operations
and <varname>errno</varname> processing (e.g.,
<option>-fast</option>).
SPARCアーキテクチャにおけるコンパイルでは、Sun Studioを強く推奨します。
特筆するような速さのバイナリを生成するため、-xO5最適化フラグを使用してみてください。
浮動小数点演算と、（-fastのような）errno演算を修正するようなフラグはすべて使ってはいけません。
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. SPARCで64ビットバイナリを使用する理由がないのであれば、32ビット版を選択してください。 64ビット操作はより遅く、64ビットバイナリは32ビット版より遅いのです。 一方で、AMD64 CPUファミリ上の32ビットコードはネイティブではありません。そのため、このCPUファミリでは32ビットコードは非常に低速です。
Yes, using DTrace is possible. See <xref linkend="dynamic-trace"/> for further information. そのとおりです。DTraceを使うことができます。より詳細な情報は28.5を参照してください。
If you see the linking of the <command>postgres</command> executable abort with an
error message like:
もし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
your DTrace installation is too old to handle probes in static functions. You need Solaris 10u4 or newer to use DTrace. DTraceのインストールが古すぎて、静的関数でプローブを処理できません。 DTraceを使用するには、Solaris 10u4以降が必要です。