Movatterモバイル変換


[0]ホーム

URL:



Facebook
Postgres Pro
Facebook
Downloads
16.7. Platform-Specific Notes
Prev UpChapter 16. Installation from Source CodeHome Next

16.7. Platform-Specific Notes

This section documents additional platform-specific issues regarding the installation and setup of PostgreSQL. Be sure to read the installation instructions, and in particularSection 16.2 as well. Also, checkChapter 32 regarding the interpretation of regression test results.

Platforms that are not covered here have no known platform-specific installation issues.

16.7.1. AIX

PostgreSQL works on AIX, but AIX versions before about 6.1 have various issues and are not recommended. You can use GCC or the native IBM compilerxlc.

16.7.1.1. Memory Management

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:

=# 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:

=# 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.

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.

In the case of theplperl 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.

Theideal 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.

If a 32-bit binary is desired, setLDR_CNTRL toMAXDATA=0xn0000000, where 1 <= n <= 8, before starting the PostgreSQL server, and try different values andpostgresql.conf settings to find a configuration that works satisfactorily. This use ofLDR_CNTRL tells AIX that you want the server to haveMAXDATA bytes set aside for the heap, allocated in 256 MB segments. When you find a workable configuration,ldedit can be used to modify the binaries so that they default to using the desired heap size. PostgreSQL can also be rebuilt, passingconfigure LDFLAGS="-Wl,-bmaxdata:0xn0000000" to achieve the same effect.

For a 64-bit build, setOBJECT_MODE to 64 and passCC="gcc -maix64" andLDFLAGS="-Wl,-bbigtoc" toconfigure. (Options forxlc might differ.) If you omit the export ofOBJECT_MODE, your build may fail with linker errors. WhenOBJECT_MODE is set, it tells AIX's build utilities such asar,as, andld what type of objects to default to handling.

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.

16.7.2. Cygwin

PostgreSQL can be built using Cygwin, a Linux-like environment for Windows, but that method is inferior to the native Windows build(seeChapter 17) and running a server under Cygwin is no longer recommended.

When building from source, proceed according to the Unix-style installation procedure (i.e.,./configure; make; etc.), noting the following Cygwin-specific differences:

  • Set your path to use the Cygwin bin directory before the Windows utilities. This will help prevent problems with compilation.

  • Theadduser command is not supported; use the appropriate user management application on Windows NT, 2000, or XP. Otherwise, skip this step.

  • Thesu command is not supported; use ssh to simulate su on Windows NT, 2000, or XP. Otherwise, skip this step.

  • OpenSSL is not supported.

  • Startcygserver for shared memory support. To do this, enter the command/usr/sbin/cygserver &. This program needs to be running anytime you start the PostgreSQL server or initialize a database cluster (initdb). The defaultcygserver configuration may need to be changed (e.g., increaseSEMMNS) to prevent PostgreSQL from failing due to a lack of system resources.

  • Building might fail on some systems where a locale other than C is in use. To fix this, set the locale to C by doingexport LANG=C.utf8 before building, and then setting it back to the previous setting after you have installed PostgreSQL.

  • The parallel regression tests (make check) can generate spurious regression test failures due to overflowing thelisten() backlog queue which causes connection refused errors or hangs. You can limit the number of connections using the make variableMAX_CONNECTIONS thus:

    make MAX_CONNECTIONS=5 check

    (On some systems you can have up to about 10 simultaneous connections.)

It is possible to installcygserver and the PostgreSQL server as Windows NT services. For information on how to do this, please refer to theREADME document included with the PostgreSQL binary package on Cygwin. It is installed in the directory/usr/share/doc/Cygwin.

16.7.3. macOS

To buildPostgreSQL from source onmacOS, you will need to install Apple's command line developer tools, which can be done by issuing

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.

On recentmacOS releases, it's necessary to embed thesysroot path in the include switches used to find some system header files. This results in the outputs of theconfigure script varying depending on which SDK version was used duringconfigure. 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, setPG_SYSROOT, for example

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.

You can also select a non-default sysroot path when configuring, by specifyingPG_SYSROOT toconfigure:

./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.

To suppress the-isysroot options altogether, use

./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.

macOS'sSystem Integrity Protection (SIP) feature breaksmake check, because it prevents passing the needed setting ofDYLD_LIBRARY_PATH down to the executables being tested. You can work around that by doingmake install beforemake check. Most PostgreSQL developers just turn off SIP, though.

16.7.4. MinGW/Native Windows

PostgreSQL for Windows can be built using MinGW, a Unix-like build environment for Microsoft operating systems, or using Microsoft'sVisual C++ 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 inChapter 17.

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 likeconfigure, can be downloaded fromhttp://www.mingw.org/. Neither is required to run the resulting binaries; they are needed only for creating the binaries.

To build 64 bit binaries using MinGW, install the 64 bit tool set fromhttps://mingw-w64.org/, put its bin directory in thePATH, and runconfigure with the--host=x86_64-w64-mingw32 option.

After you have everything installed, it is suggested that you runpsql underCMD.EXE, as the MSYS console has buffering issues.

16.7.4.1. Collecting Crash Dumps on Windows

If PostgreSQL on Windows crashes, it has the ability to generateminidumps that can be used to track down the cause for the crash, similar to core dumps on Unix. These dumps can be read using theWindows Debugger Tools or usingVisual Studio. To enable the generation of dumps on Windows, create a subdirectory namedcrashdumps 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.

16.7.5. Solaris

PostgreSQL is well-supported on Solaris. The more up to date your operating system, the fewer issues you will experience.

16.7.5.1. Required Tools

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/usr/ucb/cc; use/opt/SUNWspro/bin/cc.

You can download Sun Studio fromhttps://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/. 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 athttp://www.sunfreeware.com. If you prefer sources, look athttps://www.gnu.org/prep/ftp.

16.7.5.2. configure Complains About a Failed Test Program

Ifconfigure 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 theLDFLAGS environment variable on theconfigure command line, e.g.,

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

See theld man page for more information.

16.7.5.3. Compiling for Optimal Performance

On the SPARC architecture, Sun Studio is strongly recommended for compilation. Try using the-xO5 optimization flag to generate significantly faster binaries. Do not use any flags that modify behavior of floating-point operations anderrno processing (e.g.,-fast).

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.

16.7.5.4. Using DTrace for Tracing PostgreSQL

Yes, using DTrace is possible. SeeSection 27.5 for further information.

If you see the linking of thepostgres executable abort with an error message like:

Undefined                       first referenced symbol                             in fileAbortTransaction                    utils/probes.oCommitTransaction                   utils/probes.old: fatal: Symbol referencing errors. No output written to postgrescollect2: ld returned 1 exit statusmake: *** [postgres] Error 1

your DTrace installation is too old to handle probes in static functions. You need Solaris 10u4 or newer to use DTrace.


Prev Up Next
16.6. Supported Platforms Home Chapter 17. Installation from Source Code onWindows
pdfepub
Go to PostgreSQL 13
By continuing to browse this website, you agree to the use of cookies. Go toPrivacy Policy.

[8]ページ先頭

©2009-2025 Movatter.jp