This section documents additional platform-specific issues regarding the installation and setup of PostgreSQL. Be sure to read the installation instructions, and in particular Section 16.2 as well. Also, check Chapter 33 regarding the interpretation of regression test results.
Platforms that are not covered here have no known platform-specific installation issues.
PostgreSQL works on AIX, but getting it installed properly
can be challenging. AIX versions from 4.3.3 to 6.1 are
considered supported. You can use GCC or the native IBM
xlc. In general, using
recent versions of AIX and PostgreSQL helps. Check the build
farm for up to date information about which versions of AIX are
known to work.
The minimum recommended fix levels for supported AIX versions are:
Maintenance Level 11 + post ML11 bundle
Maintenance Level 9 + post ML9 bundle
Technology Level 10 Service Pack 3
Technology Level 7
To check your current fix level, use
oslevel -r in AIX 4.3.3 to AIX 5.2 ML 7, or
oslevel -s in later versions.
Use the following
flags in addition to your own if you have installed Readline or
On AIX 5.3, there have been some problems getting PostgreSQL to compile and run using GCC.
You will want to use a version of GCC subsequent to 3.3.2, particularly if you use a prepackaged version. We had good success with 4.0.1. Problems with earlier versions seem to have more to do with the way IBM packaged GCC than with actual issues with GCC, so that if you compile GCC yourself, you might well have success with an earlier version of GCC.
AIX 5.3 has a problem where
sockaddr_storage is not defined to be
large enough. In version 5.3, IBM increased the size of
sockaddr_un, the address
structure for Unix-domain sockets, but did not
correspondingly increase the size of
sockaddr_storage. The result of this is
that attempts to use Unix-domain sockets with PostgreSQL lead
to libpq overflowing the data structure. TCP/IP connections
work OK, but not Unix-domain sockets, which prevents the
regression tests from working.
The problem was reported to IBM, and is recorded as bug
report PMR29657. If you upgrade to maintenance level 5300-03
or later, that will include this fix. A quick workaround is
_SS_MAXSIZE to 1025 in
either case, recompile PostgreSQL once you have the corrected
PostgreSQL relies on the system's
getaddrinfo function to parse IP addresses
pg_hba.conf, etc. Older
versions of AIX have assorted bugs in this function. If you
have problems related to these settings, updating to the
appropriate AIX fix level shown above should take care of
One user reports:
When implementing PostgreSQL version 8.1 on AIX 5.3, we periodically ran into problems where the statistics collector would “mysteriously” not come up successfully. This appears to be the result of unexpected behavior in the IPv6 implementation. It looks like PostgreSQL and IPv6 do not play very well together on AIX 5.3.
Any of the following actions “fix” the problem.
Delete the IPv6 address for localhost:
(as root) # ifconfig lo0 inet6 ::1/0 delete
Remove IPv6 from net services. The file
/etc/netsvc.conf on AIX is roughly
/etc/nsswitch.conf on Solaris/Linux.
The default, on AIX, is thus:
Replace this with:
to deactivate searching for IPv6 addresses.
This is really a workaround for problems relating to immaturity of IPv6 support, which improved visibly during the course of AIX 5.3 releases. It has worked with AIX version 5.3, but does not represent an elegant solution to the problem. It has been reported that this workaround is not only unnecessary, but causes problems on AIX 6.1, where IPv6 support has become more mature.
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 the
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
The “ideal” 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, set
MAXDATA=0x, where 1
<= n <= 8, before starting the PostgreSQL server, and
try different values and
postgresql.conf settings to find a
configuration that works satisfactorily. This use of
LDR_CNTRL tells AIX that you want
the server to have
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, passing
LDFLAGS="-Wl,-bmaxdata:0x to achieve
the same effect.
For a 64-bit build, set
OBJECT_MODE to 64 and pass
CC="gcc -maix64" and
configure. (Options for
xlc might differ.) If you omit the export of
OBJECT_MODE, your build may fail
with linker errors. When
OBJECT_MODE is set, it tells AIX's build
utilities such as
ld what type of objects to default to
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.
“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.
Developing and Porting C and C++ Applications on AIX. IBM Redbook.
PostgreSQL can be built using Cygwin, a Linux-like environment for Windows, but that method is inferior to the native Windows build (see Chapter 17) and running a server under Cygwin is no longer recommended.
When building from source, proceed according to the normal
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.
adduser command is
not supported; use the appropriate user management
application on Windows NT, 2000, or XP. Otherwise, skip
su command is not
supported; use ssh to simulate su on Windows NT, 2000, or
XP. Otherwise, skip this step.
OpenSSL is not supported.
shared memory support. To do this, enter the command
This program needs to be running anytime you start the
PostgreSQL server or initialize a database cluster
initdb). The default
cygserver configuration may
need to be changed (e.g., increase
SEMMNS) 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
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 the
listen() backlog queue
which causes connection refused errors or hangs. You can
limit the number of connections using the make variable
make MAX_CONNECTIONS=5 check
(On some systems you can have up to about 10 simultaneous connections).
It is possible to install
cygserver and the PostgreSQL server as Windows
NT services. For information on how to do this, please refer to
README document included with
the PostgreSQL binary package on Cygwin. It is installed in the
PostgreSQL 7.3+ should work on Series 700/800 PA-RISC machines running HP-UX 10.X or 11.X, given appropriate system patch levels and build tools. At least one developer routinely tests on HP-UX 10.20, and we have reports of successful installations on HP-UX 11.00 and 11.11.
Aside from the PostgreSQL source distribution, you will need
GNU make (HP's make will not do), and either GCC or HP's full
ANSI C compiler. If you intend to build from Git sources rather
than a distribution tarball, you will also need Flex (GNU lex)
and Bison (GNU yacc). We also recommend making sure you are
fairly up-to-date on HP patches. At a minimum, if you are
building 64 bit binaries on HP-UX 11.11 you may need PHSS_30966
(11.11) or a successor patch otherwise
initdb may hang:
PHSS_30966 s700_800 ld(1) and linker tools cumulative patch
On general principles you should be current on libc and ld/dld patches, as well as compiler patches if you are using HP's C compiler. See HP's support sites such as ftp://us-ffs.external.hp.com/ for free copies of their latest patches.
If you are building on a PA-RISC 2.0 machine and want to have 64-bit binaries using GCC, you must use a GCC 64-bit version.
If you are building on a PA-RISC 2.0 machine and want the
compiled binaries to run on PA-RISC 1.1 machines you will need
If you are building on a HP-UX Itanium machine, you will need the latest HP ANSI C compiler with its dependent patch or successor patches:
PHSS_30848 s700_800 HP C Compiler (A.05.57)
PHSS_30849 s700_800 u2comp/be/plugin library Patch
If you have both HP's C compiler and GCC's, then you might
want to explicitly select the compiler to use when you run
for HP's C compiler, or
for GCC. If you omit this setting, then configure will pick
gcc if it has a choice.
The default install target location is
/usr/local/pgsql, which you might want to
change to something under
If so, use the
--prefix switch to
In the regression tests, there might be some low-order-digit differences in the geometry tests, which vary depending on which compiler and math library versions you use. Any other error is cause for suspicion.
On recent macOS releases,
it's necessary to embed the “sysroot” path in the include switches
used to find some system header files. This results in the
outputs of the configure
script varying depending on which SDK version was used during
configure. 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
PG_SYSROOT, for example
To find out the appropriate path on your machine, run
xcodebuild -version -sdk macosx 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 specifying
PG_SYSROOT to configure:
./configure ... PG_SYSROOT=
macOS's “System Integrity
Protection” (SIP) feature breaks
make check, because it prevents passing the
needed setting of
DYLD_LIBRARY_PATH down to the executables
being tested. You can work around that by doing
make install before
check. Most Postgres developers just turn off SIP,
PostgreSQL for Windows can be built using MinGW, a Unix-like build environment for Microsoft operating systems, or using Microsoft's Visual C++ compiler suite. The MinGW build variant uses the normal build system described in this chapter; the Visual C++ build works completely differently and is described in Chapter 17. It is a fully native build and uses no additional software like MinGW. A ready-made installer is available on the main PostgreSQL web site.
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
configure, can be downloaded from http://www.mingw.org/. Neither is required to run
the resulting binaries; they are needed only for creating the
To build 64 bit binaries using MinGW, install the 64 bit
tool set from https://mingw-w64.org/, put its bin directory
PATH, and run
configure with the
After you have everything installed, it is suggested that
you run psql under
CMD.EXE, as the MSYS console has
If PostgreSQL on Windows crashes, it has the ability to
generate minidumps 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
Windows Debugger Tools or
using Visual Studio. To
enable the generation of dumps on Windows, create a
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
PostgreSQL is well-supported on Solaris. The more up to date your operating system, the fewer issues you will experience; details below.
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. We have heard reports
of problems when using GCC 2.95.1; GCC 2.95.3 or later is
recommended. If you are using Sun's compiler, be careful not
You can download Sun Studio from https://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/. Many of GNU tools are integrated into Solaris 10, or they are present on the Solaris companion CD. If you like packages for older version of Solaris, you can find these tools at http://www.sunfreeware.com. If you prefer sources, look at https://www.gnu.org/prep/ftp.
configure 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
LDFLAGS environment variable on
configure command line,
configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
See the ld man page for more information.
On Solaris 7 and older, the 64-bit version of libc has a
vsnprintf routine, which
leads to erratic core dumps in PostgreSQL. The simplest known
workaround is to force PostgreSQL to use its own version of
vsnprintf rather than the
library copy. To do this, after you run
configure edit a file produced by
src/Makefile.global, change the line
LIBOBJS = snprintf.o
(There might be other files already listed in this variable. Order does not matter.) Then build as usual.
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 and
errno processing (e.g.,
-fast). These flags could raise some
nonstandard PostgreSQL behavior for example in the date/time
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. And on other hand, 32-bit code on the AMD64 CPU family is not native, and that is why 32-bit code is significant slower on this CPU family.
Yes, using DTrace is possible. See Section 28.5 for further information.
If you see the linking of the
postgres executable abort with an error
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.
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.