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を注意して読んでください。 またリグレッションテスト結果の解釈については第31章を確認してください。
Platforms that are not covered here have no known platform-specific installation issues. ここで触れられていないプラットフォームは、インストールに関してプラットフォーム特有の問題がありません。
PostgreSQL can be built using Cygwin, a Linux-like environment for Windows, but that method is inferior to the native Windows build and running a server under Cygwin is no longer recommended. Windowsに対するLinux的環境である、Cygwinを使ってPostgreSQLを構築できます。 しかし、この手法はWindowsネイティブビルドには及ばないので、もはや推奨されません。
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.
adduserコマンドはサポートされていません。
Windowsでは適切なユーザ管理アプリケーションを使用してください。
そうでない場合は、このステップをスキップしてください。
The <command>su</command> command is not supported; use ssh to
simulate su on Windows. Otherwise, skip this step.
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. The MinGW build procedure uses the normal build system described in this chapter. Windows用PostgreSQLは、Microsoftオペレーティングシステム用のUnixに似た構築環境であるMinGWを使って構築できます。 MinGW版の構築は本章で記述されている通常の構築システムを使用します。
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.
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を使うことができます。より詳細な情報は27.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以降が必要です。
It is recommended that most users download the binary distribution for Windows, available as a graphical installer package from the <productname>PostgreSQL</productname> website at <ulink url="https://www.postgresql.org/download/"></ulink>. Building from source is only intended for people developing <productname>PostgreSQL</productname> or extensions. ほとんどのユーザには、PostgreSQLウェブサイトのhttps://www.postgresql.org/download/からグラフィカルインストーラパッケージとして入手可能なWindows用のバイナリ配布物をダウンロードすることを推奨します。 ソースからの構築は、PostgreSQLそのもの、もしくはその拡張の開発者のみを対象としています。
PostgreSQL for Windows with Visual Studio can be built using Meson, as described in <xref linkend="install-meson"/>. The native Windows port requires a 32 or 64-bit version of Windows 10 or later. Visual Studioを使用したWindowsのPostgreSQLは、17.4で説明されているように、Mesonを使用して構築できます。 ネイティブWindowsポートには、Windows 10以降の32または64ビットバージョンが必要です。
Native builds of <application>psql</application> don't support command line editing. The <productname>Cygwin</productname> build does support command line editing, so it should be used where psql is needed for interactive use on <productname>Windows</productname>. psqlのネイティブビルドはコマンドライン編集をサポートしていません。 Cygwinによる構築はコマンドライン編集をサポートしているので、Windows上でpsqlを対話形式で使用する必要がある場合は、こちらを使うことが推奨されます。
PostgreSQL can be built using the Visual C++ compiler suite from Microsoft. These compilers can be either from <productname>Visual Studio</productname>, <productname>Visual Studio Express</productname> or some versions of the <productname>Microsoft Windows SDK</productname>. If you do not already have a <productname>Visual Studio</productname> environment set up, the easiest ways are to use the compilers from <productname>Visual Studio 2022</productname> or those in the <productname>Windows SDK 10</productname>, which are both free downloads from Microsoft. PostgreSQLは、MicrosoftのVisual C++コンパイラ一式を使って構築できます。 これらのコンパイラは、Visual Studio、Visual Studio Express、またはMicrosoft Windows SDKのいくつかのバージョンから入手できます。 Visual Studio環境をまだ設定していない場合、最も簡単な方法は、Visual Studio 2022のコンパイラか、Microsoftから無料でダウンロードできるWindows SDK 10のコンパイラを使用することです。
Both 32-bit and 64-bit builds are possible with the Microsoft Compiler suite. 32-bit PostgreSQL builds are possible with <productname>Visual Studio 2015</productname> to <productname>Visual Studio 2022</productname>, as well as standalone Windows SDK releases 10 and above. 64-bit PostgreSQL builds are supported with <productname>Microsoft Windows SDK</productname> version 10 and above or <productname>Visual Studio 2015</productname> and above. Microsoftコンパイラ一式で、32ビットと64ビットの両方のビルドが可能です。 PostgreSQLの32-ビットビルドは、Visual Studio 2015からVisual Studio 2022、およびスタンドアローンWindows SDKリリース10以降で可能です。 PostgreSQLの64-ビットビルドは、Microsoft Windows SDKバージョン10以降またはVisual Studio 2015以降でサポートされています。 For 2015 requirements: https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2015-sysrequirements-vs For 2017 requirements: https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2017-system-requirements-vs For 2019 requirements: https://docs.microsoft.com/en-us/visualstudio/releases/2019/system-requirements For 2022 requirements: https://docs.microsoft.com/en-us/visualstudio/releases/2022/system-requirements
If your build environment doesn't ship with a supported version of the <productname>Microsoft Windows SDK</productname> it is recommended that you upgrade to the latest version (currently version 10), available for download from <ulink url="https://www.microsoft.com/download"></ulink>. お使いのビルド環境にサポートされているMicrosoft Windows SDKのバージョンが同梱されていない場合は、https://www.microsoft.com/downloadからダウンロード可能な最新版（現在はバージョン10）にアップグレードすることを推奨します。
You must always include the <application>Windows Headers and Libraries</application> part of the SDK. If you install a <productname>Windows SDK</productname> including the <application>Visual C++ Compilers</application>, you don't need <productname>Visual Studio</productname> to build. Note that as of Version 8.0a the Windows SDK no longer ships with a complete command-line build environment. SDKのWindows Headers and Librariesを常にインクルードしなければなりません。 Visual C++ Compilersを含むWindows SDKをインストールしている場合、構築のためにVisual Studioは必要ありません。 バージョン8.0aでは、Windows SDKは完全なコマンドライン構築環境を提供していないことに注意してください。
The following additional products are required to build <productname>PostgreSQL</productname> on Windows. WindowsでPostgreSQLを構築するには、以下のソフトウェアパッケージが必要です。
ActiveState Perl is required to run the build generation scripts. MinGW or Cygwin Perl will not work. It must also be present in the PATH. Binaries can be downloaded from <ulink url="https://www.activestate.com"></ulink> (Note: version 5.14 or later is required, the free Standard Distribution is sufficient). ビルド生成スクリプトを実行するには、ActiveState Perlが必要です。 MinGWまたはCygwinのPerlは動作しません。 また、PATHに存在する必要があります。 バイナリはhttps://www.activestate.comからダウンロードできます（注:バージョン5.14以降が必要です。 無料の標準配布で十分です）。
<productname>Bison</productname> and <productname>Flex</productname> are required. Only <productname>Bison</productname> versions 2.3 and later will work. <productname>Flex</productname> must be version 2.5.35 or later. BisonとFlexが必要です。 Bisonのバージョン2.3以降のみが動作します。 Flexはバージョン2.5.35以降でなければなりません。
Both <productname>Bison</productname> and <productname>Flex</productname> are included in the <productname>msys</productname> tool suite, available from <ulink url="http://www.mingw.org/wiki/MSYS"></ulink> as part of the <productname>MinGW</productname> compiler suite. BisonおよびFlexの両方が、MinGWコンパイラ一式の一部としてhttp://www.mingw.org/wiki/MSYSから入手できる、msysツール一式に含まれています。
You will need to add the directory containing
<filename>flex.exe</filename> and <filename>bison.exe</filename> to the
PATH environment variable. In the case of MinGW, the directory is the
<filename>\msys\1.0\bin</filename> subdirectory of your MinGW
installation directory.
flex.exeとbison.exeを含むディレクトリをPATH環境変数に追加する必要があります。
MinGWの場合、ディレクトリはMinGWインストールディレクトリの\msys\1.0\binサブディレクトリです。
The Bison distribution from GnuWin32 appears to have a bug that
causes Bison to malfunction when installed in a directory with
spaces in the name, such as the default location on English
installations <filename>C:\Program Files\GnuWin32</filename>.
Consider installing into <filename>C:\GnuWin32</filename> or use the
NTFS short name path to GnuWin32 in your PATH environment setting
(e.g., <filename>C:\PROGRA~1\GnuWin32</filename>).
GnuWin32のBisonディストリビューションでは、C:\Program Files\GnuWin32の様に名前に空白を持つディレクトリにインストールされると正常に機能しないというバグがあります。
代わりにC:\GnuWin32へのインストール、または、PATH環境設定におけるGnuWin32へのNTFSショートネームパスの使用（例えばC:\PROGRA~1\GnuWin32）を検討してください。
The following additional products are not required to get started, but are required to build the complete package. 次の追加製品は、開始するために必要ではありませんが、完全なパッケージを構築するために必要です。
Required for building <application>PL/Tcl</application> (Note: version 8.4 is required, the free Standard Distribution is sufficient). PL/Tclを構築する時に必要です（注意：バージョン8.4が必要です。 無料の標準配布で十分です）。
Diff is required to run the regression tests, and can be downloaded from <ulink url="http://gnuwin32.sourceforge.net"></ulink>. リグレッションテストを実行するにはdiffが必要です。 http://gnuwin32.sourceforge.netからダウンロードできます。
Gettext is required to build with NLS support, and can be downloaded from <ulink url="http://gnuwin32.sourceforge.net"></ulink>. Note that binaries, dependencies and developer files are all needed. NLSサポート付きで構築する場合はgettextが必要です。 http://gnuwin32.sourceforge.netからダウンロードできます。 バイナリ、依存物、開発用ファイルすべてが必要であることに注意してください。
Required for GSSAPI authentication support. MIT Kerberos can be downloaded from <ulink url="https://web.mit.edu/Kerberos/dist/index.html"></ulink>. GSSAPI認証をサポートする場合に必要です。 MIT Kerberosはhttps://web.mit.edu/Kerberos/dist/index.htmlからダウンロードできます。
Required for XML support. Binaries can be downloaded from <ulink url="https://zlatkovic.com/pub/libxml"></ulink> or source from <ulink url="http://xmlsoft.org"></ulink>. Note that libxml2 requires iconv, which is available from the same download location. XMLサポートのために必要です。 バイナリはhttps://zlatkovic.com/pub/libxmlから、ソースはhttp://xmlsoft.orgからダウンロードできます。 libxml2はiconvを必要とすることに注意してください。 同じ場所からダウンロードできます。
Required for supporting <productname>LZ4</productname> compression. Binaries and source can be downloaded from <ulink url="https://github.com/lz4/lz4/releases"></ulink>. LZ4圧縮方式のサポートのために必要です。 バイナリとソースはhttps://github.com/lz4/lz4/releasesからダウンロードできます。
Required for supporting <productname>Zstandard</productname> compression. Binaries and source can be downloaded from <ulink url="https://github.com/facebook/zstd/releases"></ulink>. Zstandard圧縮方式のサポートのために必要です。 バイナリとソースはhttps://github.com/facebook/zstd/releasesからダウンロードできます。
Required for SSL support. Binaries can be downloaded from <ulink url="https://slproweb.com/products/Win32OpenSSL.html"></ulink> or source from <ulink url="https://www.openssl.org"></ulink>. SSLサポートのために必要です。 バイナリはhttps://slproweb.com/products/Win32OpenSSL.htmlから、ソースはhttps://www.openssl.orgからダウンロードできます。
Required for UUID-OSSP support (contrib only). Source can be downloaded from <ulink url="http://www.ossp.org/pkg/lib/uuid/"></ulink>. UUID-OSSPサポート（contribのみ）で必要です。 ソースはhttp://www.ossp.org/pkg/lib/uuid/からダウンロードできます。
Required for building <application>PL/Python</application>. Binaries can be downloaded from <ulink url="https://www.python.org"></ulink>. PL/Pythonを構築する場合に必要です。 バイナリはhttps://www.python.orgからダウンロードできます。
Required for compression support in <application>pg_dump</application> and <application>pg_restore</application>. Binaries can be downloaded from <ulink url="https://www.zlib.net"></ulink>. pg_dumpおよびpg_restoreにおける圧縮をサポートするために必要です。 バイナリはhttps://www.zlib.netからダウンロードできます。
PostgreSQL will only build for the x64 architecture on 64-bit Windows. 64ビット版Windowsにおいてx64アーキテクチャのみPostgreSQLを構築できます。
Mixing 32- and 64-bit versions in the same build tree is not supported. The build system will automatically detect if it's running in a 32- or 64-bit environment, and build PostgreSQL accordingly. For this reason, it is important to start the correct command prompt before building. 同じ構築用ツリーで32ビット版と64ビット版を混在させることはサポートされません。 構築システムは32ビット環境で動作しているか64ビット環境で動作しているかを自動的に検出し、それにしたがってPostgreSQLを構築します。 このため構築作業を始める前に正しいコマンドプロンプトを開始することが重要です。
To use a server-side third party library such as <productname>Python</productname> or <productname>OpenSSL</productname>, this library <emphasis>must</emphasis> also be 64-bit. There is no support for loading a 32-bit library in a 64-bit server. Several of the third party libraries that PostgreSQL supports may only be available in 32-bit versions, in which case they cannot be used with 64-bit PostgreSQL. PythonやOpenSSLなどのサーバサイドのサードパーティ製ライブラリを使用するためには、ライブラリも64ビット版である必要があります。 64ビット版のサーバで32ビット版のライブラリをロードすることはサポートされていません。 PostgreSQLがサポートするサードパーティ製のライブラリで32ビット版しか利用できないものが複数あります。 こうした場合、64ビット版のPostgreSQLで使用することはできません。
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という名前のサブディレクトリをデータベースクラスタディレクトリの中に作成します。
ダンプは、クラッシュ時の現在時間と原因となったプロセスの識別子を元にした一意な名前としてこのディレクトリの中に生成されます。