<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>16.7. Platform-specific Notes</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="supported-platforms.html" title="16.6. Supported Platforms" /><link rel="next" href="install-windows.html" title="Chapter 17. Installation from Source Code on Windows" /></head><body><div xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">16.7. Platform-specific Notes</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="supported-platforms.html" title="16.6. Supported Platforms">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="installation.html" title="Chapter 16. Installation from Source Code">Up</a></td><th width="60%" align="center">Chapter 16. Installation from Source Code</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 11.5 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="install-windows.html" title="Chapter 17. Installation from Source Code on Windows">Next</a></td></tr></table><hr></hr></div><div class="sect1" id="INSTALLATION-PLATFORM-NOTES"><div class="titlepage"><div><div><h2 class="title" style="clear: both">16.7. Platform-specific Notes</h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="installation-platform-notes.html#INSTALLATION-NOTES-AIX">16.7.1. AIX</a></span></dt><dt><span class="sect2"><a href="installation-platform-notes.html#INSTALLATION-NOTES-CYGWIN">16.7.2. Cygwin</a></span></dt><dt><span class="sect2"><a href="installation-platform-notes.html#INSTALLATION-NOTES-HPUX">16.7.3. HP-UX</a></span></dt><dt><span class="sect2"><a href="installation-platform-notes.html#INSTALLATION-NOTES-MACOS">16.7.4. macOS</a></span></dt><dt><span class="sect2"><a href="installation-platform-notes.html#INSTALLATION-NOTES-MINGW">16.7.5. MinGW/Native Windows</a></span></dt><dt><span class="sect2"><a href="installation-platform-notes.html#INSTALLATION-NOTES-SOLARIS">16.7.6. Solaris</a></span></dt></dl></div><p>
This section documents additional platform-specific issues
regarding the installation and setup of PostgreSQL. Be sure to
read the installation instructions, and in
particular <a class="xref" href="install-requirements.html" title="16.2. Requirements">Section 16.2</a> as well. Also,
check <a class="xref" href="regress.html" title="Chapter 33. Regression Tests">Chapter 33</a> regarding the
interpretation of regression test results.
</p><p>
Platforms that are not covered here have no known platform-specific
installation issues.
</p><div class="sect2" id="INSTALLATION-NOTES-AIX"><div class="titlepage"><div><div><h3 class="title">16.7.1. AIX</h3></div></div></div><a id="id-1.6.3.10.4.2" class="indexterm"></a><p>
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 compiler <code class="command">xlc</code>. 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.
</p><p>
The minimum recommended fix levels for supported AIX versions are:
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">AIX 4.3.3</span></dt><dd><p>Maintenance Level 11 + post ML11 bundle</p></dd><dt><span class="term">AIX 5.1</span></dt><dd><p>Maintenance Level 9 + post ML9 bundle</p></dd><dt><span class="term">AIX 5.2</span></dt><dd><p>Technology Level 10 Service Pack 3</p></dd><dt><span class="term">AIX 5.3</span></dt><dd><p>Technology Level 7</p></dd><dt><span class="term">AIX 6.1</span></dt><dd><p>Base Level</p></dd></dl></div><p>
To check your current fix level, use
<code class="command">oslevel -r</code> in AIX 4.3.3 to AIX 5.2 ML 7, or
<code class="command">oslevel -s</code> in later versions.
</p><p>
Use the following <code class="command">configure</code> flags in addition
to your own if you have installed Readline or libz in
<code class="literal">/usr/local</code>:
<code class="literal">--with-includes=/usr/local/include
--with-libraries=/usr/local/lib</code>.
</p><div class="sect3" id="id-1.6.3.10.4.8"><div class="titlepage"><div><div><h4 class="title">16.7.1.1. GCC Issues</h4></div></div></div><p>
On AIX 5.3, there have been some problems getting PostgreSQL to
compile and run using GCC.
</p><p>
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.
</p></div><div class="sect3" id="id-1.6.3.10.4.9"><div class="titlepage"><div><div><h4 class="title">16.7.1.2. Unix-Domain Sockets Broken</h4></div></div></div><p>
AIX 5.3 has a problem
where <code class="structname">sockaddr_storage</code> is not defined to
be large enough. In version 5.3, IBM increased the size of
<code class="structname">sockaddr_un</code>, the address structure for
Unix-domain sockets, but did not correspondingly increase the
size of <code class="structname">sockaddr_storage</code>. 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.
</p><p>
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 to alter <code class="symbol">_SS_MAXSIZE</code> to 1025 in
<code class="filename">/usr/include/sys/socket.h</code>. In either case,
recompile PostgreSQL once you have the corrected header file.
</p></div><div class="sect3" id="id-1.6.3.10.4.10"><div class="titlepage"><div><div><h4 class="title">16.7.1.3. Internet Address Issues</h4></div></div></div><p>
PostgreSQL relies on the system's <code class="function">getaddrinfo</code> function
to parse IP addresses in <code class="varname">listen_addresses</code>,
<code class="filename">pg_hba.conf</code>, 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 it.
</p><p>
One user reports:
</p><p>
When implementing PostgreSQL version 8.1 on AIX 5.3, we
periodically ran into problems where the statistics collector
would <span class="quote">“<span class="quote">mysteriously</span>”</span> 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.
</p><p>
Any of the following actions <span class="quote">“<span class="quote">fix</span>”</span> the problem.
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
Delete the IPv6 address for localhost:
</p><pre class="screen">
(as root)
# ifconfig lo0 inet6 ::1/0 delete
</pre><p>
</p></li><li class="listitem"><p>
Remove IPv6 from net services. The
file <code class="filename">/etc/netsvc.conf</code> on AIX is roughly
equivalent to <code class="filename">/etc/nsswitch.conf</code> on
Solaris/Linux. The default, on AIX, is thus:
</p><pre class="programlisting">
hosts=local,bind
</pre><p>
Replace this with:
</p><pre class="programlisting">
hosts=local4,bind4
</pre><p>
to deactivate searching for IPv6 addresses.
</p></li></ul></div><p>
</p><div class="warning"><h3 class="title">Warning</h3><p>
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.
</p></div></div><div class="sect3" id="id-1.6.3.10.4.11"><div class="titlepage"><div><div><h4 class="title">16.7.1.4. Memory Management</h4></div></div></div><p>
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:
</p><pre class="screen">
=# 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.
</pre><p>
Running as a non-owner in the group possessing the PostgreSQL
installation:
</p><pre class="screen">
=# CREATE EXTENSION plperl;
ERROR: could not load library "/opt/dbs/pgsql/lib/plperl.so": Bad address
</pre><p>
Another example is out of memory errors in the PostgreSQL server
logs, with every memory allocation near or greater than 256 MB
failing.
</p><p>
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.
</p><p>
In the case of the <code class="literal">plperl</code> 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.
</p><p>
The <span class="quote">“<span class="quote">ideal</span>”</span> 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.
</p><p>
If a 32-bit binary is desired, set <code class="symbol">LDR_CNTRL</code> to
<code class="literal">MAXDATA=0x<em class="replaceable"><code>n</code></em>0000000</code>,
where 1 <= n <= 8, before starting the PostgreSQL server,
and try different values and <code class="filename">postgresql.conf</code>
settings to find a configuration that works satisfactorily. This
use of <code class="symbol">LDR_CNTRL</code> tells AIX that you want the
server to have <code class="symbol">MAXDATA</code> bytes set aside for the
heap, allocated in 256 MB segments. When you find a workable
configuration,
<code class="command">ldedit</code> can be used to modify the binaries so
that they default to using the desired heap size. PostgreSQL can
also be rebuilt, passing <code class="literal">configure
LDFLAGS="-Wl,-bmaxdata:0x<em class="replaceable"><code>n</code></em>0000000"</code>
to achieve the same effect.
</p><p>
For a 64-bit build, set <code class="envar">OBJECT_MODE</code> to 64 and
pass <code class="literal">CC="gcc -maix64"</code>
and <code class="literal">LDFLAGS="-Wl,-bbigtoc"</code>
to <code class="command">configure</code>. (Options for
<code class="command">xlc</code> might differ.) If you omit the export of
<code class="envar">OBJECT_MODE</code>, your build may fail with linker errors. When
<code class="envar">OBJECT_MODE</code> is set, it tells AIX's build utilities
such as <code class="command">ar</code>, <code class="command">as</code>, and <code class="command">ld</code> what
type of objects to default to handling.
</p><p>
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.
</p><div class="bibliography" id="id-1.6.3.10.4.11.9"><div class="titlepage"><div><div><h5 class="title">References and Resources</h5></div></div></div><div class="biblioentry" id="id-1.6.3.10.4.11.9.2"><p><span class="biblioset">“<a class="ulink" href="http://publib.boulder.ibm.com/infocenter/pseries/topic/com.ibm.aix.doc/aixprggd/genprogc/lrg_prg_support.htm" target="_top">Large Program Support</a>”. </span><span class="biblioset"><em>AIX Documentation: General Programming Concepts: Writing and Debugging Programs</em>. </span></p></div><div class="biblioentry" id="id-1.6.3.10.4.11.9.3"><p><span class="biblioset">“<a class="ulink" href="http://publib.boulder.ibm.com/infocenter/pseries/topic/com.ibm.aix.doc/aixprggd/genprogc/address_space.htm" target="_top">Program Address Space Overview</a>”. </span><span class="biblioset"><em>AIX Documentation: General Programming Concepts: Writing and Debugging Programs</em>. </span></p></div><div class="biblioentry" id="id-1.6.3.10.4.11.9.4"><p><span class="biblioset">“<a class="ulink" href="http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/aixbman/prftungd/resmgmt2.htm" target="_top">Performance Overview of the Virtual Memory Manager (VMM)</a>”. </span><span class="biblioset"><em>AIX Documentation: Performance Management Guide</em>. </span></p></div><div class="biblioentry" id="id-1.6.3.10.4.11.9.5"><p><span class="biblioset">“<a class="ulink" href="http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/aixbman/prftungd/memperf7.htm" target="_top">Page Space Allocation</a>”. </span><span class="biblioset"><em>AIX Documentation: Performance Management Guide</em>. </span></p></div><div class="biblioentry" id="id-1.6.3.10.4.11.9.6"><p><span class="biblioset">“<a class="ulink" href="http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/aixbman/prftungd/memperf6.htm" target="_top">Paging-space thresholds tuning</a>”. </span><span class="biblioset"><em>AIX Documentation: Performance Management Guide</em>. </span></p></div><div class="biblioentry" id="id-1.6.3.10.4.11.9.7"><p><span class="title"><em><a class="ulink" href="http://www.redbooks.ibm.com/abstracts/sg245674.html?Open" target="_top">Developing and Porting C and C++ Applications on AIX</a></em>. </span><span class="publisher"><span class="publishername">IBM Redbook. </span></span></p></div></div></div></div><div class="sect2" id="INSTALLATION-NOTES-CYGWIN"><div class="titlepage"><div><div><h3 class="title">16.7.2. Cygwin</h3></div></div></div><a id="id-1.6.3.10.5.2" class="indexterm"></a><p>
PostgreSQL can be built using Cygwin, a Linux-like environment for
Windows, but that method is inferior to the native Windows build
<span class="phrase">(see <a class="xref" href="install-windows.html" title="Chapter 17. Installation from Source Code on Windows">Chapter 17</a>)</span> and
running a server under Cygwin is no longer recommended.
</p><p>
When building from source, proceed according to the normal
installation procedure (i.e., <code class="literal">./configure;
make</code>; etc.), noting the following-Cygwin specific
differences:
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
Set your path to use the Cygwin bin directory before the
Windows utilities. This will help prevent problems with
compilation.
</p></li><li class="listitem"><p>
The <code class="command">adduser</code> command is not supported; use
the appropriate user management application on Windows NT,
2000, or XP. Otherwise, skip this step.
</p></li><li class="listitem"><p>
The <code class="command">su</code> command is not supported; use ssh to
simulate su on Windows NT, 2000, or XP. Otherwise, skip this
step.
</p></li><li class="listitem"><p>
OpenSSL is not supported.
</p></li><li class="listitem"><p>
Start <code class="command">cygserver</code> for shared memory support.
To do this, enter the command <code class="literal">/usr/sbin/cygserver
&</code>. This program needs to be running anytime you
start the PostgreSQL server or initialize a database cluster
(<code class="command">initdb</code>). The
default <code class="command">cygserver</code> configuration may need to
be changed (e.g., increase <code class="symbol">SEMMNS</code>) to prevent
PostgreSQL from failing due to a lack of system resources.
</p></li><li class="listitem"><p>
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
<code class="command">export LANG=C.utf8</code> before building, and then
setting it back to the previous setting, after you have installed
PostgreSQL.
</p></li><li class="listitem"><p>
The parallel regression tests (<code class="literal">make check</code>)
can generate spurious regression test failures due to
overflowing the <code class="function">listen()</code> backlog queue
which causes connection refused errors or hangs. You can limit
the number of connections using the make
variable <code class="varname">MAX_CONNECTIONS</code> thus:
</p><pre class="programlisting">
make MAX_CONNECTIONS=5 check
</pre><p>
(On some systems you can have up to about 10 simultaneous
connections).
</p></li></ul></div><p>
</p><p>
It is possible to install <code class="command">cygserver</code> and the
PostgreSQL server as Windows NT services. For information on how
to do this, please refer to the <code class="filename">README</code>
document included with the PostgreSQL binary package on Cygwin.
It is installed in the
directory <code class="filename">/usr/share/doc/Cygwin</code>.
</p></div><div class="sect2" id="INSTALLATION-NOTES-HPUX"><div class="titlepage"><div><div><h3 class="title">16.7.3. HP-UX</h3></div></div></div><a id="id-1.6.3.10.6.2" class="indexterm"></a><p>
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.
</p><p>
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 <code class="command">initdb</code> may hang:
</p><div class="literallayout"><p><br />
PHSS_30966 s700_800 ld(1) and linker tools cumulative patch<br />
</p></div><p>
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 <a class="ulink" href="ftp://us-ffs.external.hp.com/" target="_top">ftp://us-ffs.external.hp.com/</a> for free
copies of their latest patches.
</p><p>
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.
</p><p>
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 to specify
<code class="option">+DAportable</code> in <code class="envar">CFLAGS</code>.
</p><p>
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:
</p><div class="literallayout"><p><br />
PHSS_30848 s700_800 HP C Compiler (A.05.57)<br />
PHSS_30849 s700_800 u2comp/be/plugin library Patch<br />
</p></div><p>
</p><p>
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 <code class="command">configure</code>:
</p><pre class="programlisting">
./configure CC=cc
</pre><p>
for HP's C compiler, or
</p><pre class="programlisting">
./configure CC=gcc
</pre><p>
for GCC. If you omit this setting, then configure will
pick <code class="command">gcc</code> if it has a choice.
</p><p>
The default install target location
is <code class="filename">/usr/local/pgsql</code>, which you might want to
change to something under <code class="filename">/opt</code>. If so, use
the
<code class="option">--prefix</code> switch to <code class="command">configure</code>.
</p><p>
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.
</p></div><div class="sect2" id="INSTALLATION-NOTES-MACOS"><div class="titlepage"><div><div><h3 class="title">16.7.4. macOS</h3></div></div></div><a id="id-1.6.3.10.7.2" class="indexterm"></a><p>
On recent <span class="productname">macOS</span> releases, it's necessary to
embed the <span class="quote">“<span class="quote">sysroot</span>”</span> path in the include switches used to
find some system header files. This results in the outputs of
the <span class="application">configure</span> script varying depending on
which SDK version was used during <span class="application">configure</span>.
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 <code class="varname">PG_SYSROOT</code>,
for example
</p><pre class="programlisting">
make PG_SYSROOT=<em class="replaceable"><code>/desired/path</code></em> all
</pre><p>
To find out the appropriate path on your machine, run
</p><pre class="programlisting">
xcodebuild -version -sdk macosx Path
</pre><p>
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.
</p><p>
You can also select a non-default sysroot path when configuring, by
specifying <code class="varname">PG_SYSROOT</code>
to <span class="application">configure</span>:
</p><pre class="programlisting">
./configure ... PG_SYSROOT=<em class="replaceable"><code>/desired/path</code></em>
</pre><p>
</p><p>
<span class="productname">macOS</span>'s <span class="quote">“<span class="quote">System Integrity
Protection</span>”</span> (SIP) feature breaks <code class="literal">make check</code>,
because it prevents passing the needed setting
of <code class="literal">DYLD_LIBRARY_PATH</code> down to the executables being
tested. You can work around that by doing <code class="literal">make
install</code> before <code class="literal">make check</code>.
Most Postgres developers just turn off SIP, though.
</p></div><div class="sect2" id="INSTALLATION-NOTES-MINGW"><div class="titlepage"><div><div><h3 class="title">16.7.5. MinGW/Native Windows</h3></div></div></div><a id="id-1.6.3.10.8.2" class="indexterm"></a><p>
PostgreSQL for Windows can be built using MinGW, a Unix-like build
environment for Microsoft operating systems, or using
Microsoft's <span class="productname">Visual C++</span> 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 <a class="xref" href="install-windows.html" title="Chapter 17. Installation from Source Code on Windows">Chapter 17</a>.
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.
</p><p>
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 <code class="command">configure</code>, can be downloaded
from <a class="ulink" href="http://www.mingw.org/" target="_top">http://www.mingw.org/</a>. Neither is
required to run the resulting binaries; they are needed only for
creating the binaries.
</p><p>
To build 64 bit binaries using MinGW, install the 64 bit tool set
from <a class="ulink" href="https://mingw-w64.org/" target="_top">https://mingw-w64.org/</a>, put its bin
directory in the <code class="envar">PATH</code>, and run
<code class="command">configure</code> with the
<code class="command">--host=x86_64-w64-mingw32</code> option.
</p><p>
After you have everything installed, it is suggested that you
run <span class="application">psql</span>
under <code class="command">CMD.EXE</code>, as the MSYS console has
buffering issues.
</p><div class="sect3" id="WINDOWS-CRASH-DUMPS"><div class="titlepage"><div><div><h4 class="title">16.7.5.1. Collecting Crash Dumps on Windows</h4></div></div></div><p>
If PostgreSQL on Windows crashes, it has the ability to generate
<span class="productname">minidumps</span> 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 <span class="productname">Windows Debugger Tools</span> or using
<span class="productname">Visual Studio</span>. To enable the generation of dumps
on Windows, create a subdirectory named <code class="filename">crashdumps</code>
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.
</p></div></div><div class="sect2" id="INSTALLATION-NOTES-SOLARIS"><div class="titlepage"><div><div><h3 class="title">16.7.6. Solaris</h3></div></div></div><a id="id-1.6.3.10.9.2" class="indexterm"></a><p>
PostgreSQL is well-supported on Solaris. The more up to date your
operating system, the fewer issues you will experience; details
below.
</p><div class="sect3" id="id-1.6.3.10.9.4"><div class="titlepage"><div><div><h4 class="title">16.7.6.1. Required Tools</h4></div></div></div><p>
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 to select
<code class="filename">/usr/ucb/cc</code>;
use <code class="filename">/opt/SUNWspro/bin/cc</code>.
</p><p>
You can download Sun Studio
from <a class="ulink" href="https://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/" target="_top">https://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/</a>.
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 <a class="ulink" href="http://www.sunfreeware.com" target="_top">http://www.sunfreeware.com</a>.
If you prefer
sources, look
at <a class="ulink" href="https://www.gnu.org/prep/ftp" target="_top">https://www.gnu.org/prep/ftp</a>.
</p></div><div class="sect3" id="id-1.6.3.10.9.5"><div class="titlepage"><div><div><h4 class="title">16.7.6.2. configure Complains About a Failed Test Program</h4></div></div></div><p>
If <code class="command">configure</code> 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 <code class="envar">LDFLAGS</code> environment
variable on the <code class="command">configure</code> command line, e.g.,
</p><pre class="programlisting">
configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
</pre><p>
See
the <span class="citerefentry"><span class="refentrytitle">ld</span></span>
man page for more information.
</p></div><div class="sect3" id="id-1.6.3.10.9.6"><div class="titlepage"><div><div><h4 class="title">16.7.6.3. 64-bit Build Sometimes Crashes</h4></div></div></div><p>
On Solaris 7 and older, the 64-bit version of libc has a buggy
<code class="function">vsnprintf</code> routine, which leads to erratic
core dumps in PostgreSQL. The simplest known workaround is to
force PostgreSQL to use its own version of <code class="function">vsnprintf</code> rather than
the library copy. To do this, after you
run <code class="command">configure</code> edit a file produced by
<code class="command">configure</code>:
In <code class="filename">src/Makefile.global</code>, change the line
</p><pre class="programlisting">
LIBOBJS =
</pre><p>
to read
</p><pre class="programlisting">
LIBOBJS = snprintf.o
</pre><p>
(There might be other files already listed in this variable.
Order does not matter.) Then build as usual.
</p></div><div class="sect3" id="id-1.6.3.10.9.7"><div class="titlepage"><div><div><h4 class="title">16.7.6.4. Compiling for Optimal Performance</h4></div></div></div><p>
On the SPARC architecture, Sun Studio is strongly recommended for
compilation. Try using the <code class="option">-xO5</code> optimization
flag to generate significantly faster binaries. Do not use any
flags that modify behavior of floating-point operations
and <code class="varname">errno</code> processing (e.g.,
<code class="option">-fast</code>). These flags could raise some
nonstandard PostgreSQL behavior for example in the date/time
computing.
</p><p>
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.
</p></div><div class="sect3" id="id-1.6.3.10.9.8"><div class="titlepage"><div><div><h4 class="title">16.7.6.5. Using DTrace for Tracing PostgreSQL</h4></div></div></div><p>
Yes, using DTrace is possible. See <a class="xref" href="dynamic-trace.html" title="28.5. Dynamic Tracing">Section 28.5</a> for
further information.
</p><p>
If you see the linking of the <code class="command">postgres</code> executable abort with an
error message like:
</p><pre class="screen">
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
</pre><p>
your DTrace installation is too old to handle probes in static
functions. You need Solaris 10u4 or newer.
</p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="supported-platforms.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="installation.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="install-windows.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">16.6. Supported Platforms </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 17. Installation from Source Code on <span class="productname">Windows</span></td></tr></table></div></body></html>
