PostgreSQL

PostgreSQL is a free and open source relational database. It supports such things as transactions, schemata and foreign keys, and is often touted to more strictly adhere to the SQL standards than any other database, commercial or otherwise.

Preface
The new Ebuilds &mdash; the old Ebuilds being, , and  &mdash; in Portage feature slotting matching the major version. This allows you to have two major versions of PostgreSQL operating simultaneously; 8.3 and 8.4 can serve at the same time. This is useful in such circumstances where you need to move data from an older database to a new database, or need to have a production and a testing database on the same machine. Also, this prevents a database, corresponding libraries or executables from being overwritten by an incompatible update.

The greatest benefit reaped from this slotting method being that bug and security fixes, which are delivered via minor version updates, can be applied without fear of corrupting data; 8.4.1 can be updated to 8.4.2 as they're guaranteed to be compatible, in the same slot and require no more interaction from you than to emerge it &mdash; no configuration necessary.

Read PostgreSQL's Versioning Policy for more information.

USE Flags

 * Include the documentation. This documentation is the same as you'd read online.
 * Utilize Kerberos authentication.
 * Support for LDAP authentication and connection parameter lookup.
 * Enable the ability to display messages in a language other than English. Used in conjunction with the Portage variable LINGUAS.
 * Pluggable Authentication Module support.
 * Enable support for using Perl to write functions and trigger procedures.
 * Use the newer method for formatting time stamps. Unless you had a previous installation that utilized the deprecated method, leave this enabled.
 * Use the older method for formatting time stamps. Unless you had a previous installation that utilized the deprecated method, leave this disabled.
 * Enable support for using Python to write functions and trigger procedures.
 * You really want this enabled. Disabling removes command line editing and history in psql.
 * Install respective SELinux policy. This can only be enabled by using the SELinux profile.
 * Enable support for SSL connections.
 * Enable support for using Tcl to write functions and trigger procedures.
 * Make the client libraries thread-safe. The rest of your system must be thread-safe as well.
 * Include support to generate a 128 bit random unique identifier. This is useful for merging databases together as the chances of collision are extremely low.
 * Enable SQL/XML support.
 * Support for compressed archives in pg_dump and pg_restore.

Start Emerging
Example output of emerge -av dev-db/postgresql-server You may receive a notice regarding that any of the above packages are blocked by any or all of the following packages: dev-db/postgresql-libs, dev-db/postgresql-client, dev-db/libpq or dev-db/postgresql. These packages are not maintained and are ancient. If you're currently using a database via one of those packages, dump the database then unmerge them.

You may break some packages that were built against those ancient packages, but once you've installed dev-db/postgresql-base, you can run to reemerge any packages that may have been broken.

Before Finalizing the Installation
Once the packages have finished emerging, you must edit, where *.* is the major version. There are two lines that effect the base installation of the server and cannot be changed later without deleting the directory that contains the database and reinstalling.

PGDATA defines where to place the database and related files. PG_INITDB_OPTS must contain at the very least --locale=locale. PG_INITDB_OPTS may contain any extra options you'd care to set. The extra options are not required as the reasonable defaults are, ahem, reasonable.

In the following example, PGDATA states that the database directory should be located to. If you decide to stray from the default, bear in mind that it is a very good idea to keep the major version in the path. PG_INITDB_OPTS states that the default locale should be en_US.UTF-8. That is, U.S. English ordering and formatting, and UTF-8 character encoding.

You can specify different locales to be used in the same database cluster. If you decide to exclude --locale=, then all six of the other options must be set.


 * --lc-collate=locale: String sort order
 * --lc-ctype=locale: Character classification (What is a letter? Its upper-case equivalent?)
 * --lc-messages=locale - Language of messages
 * --lc-monetary=locale - Formatting of currency amounts
 * --lc-numeric=locale - Formatting of numbers
 * --lc-time=locale - Formatting of dates and times

So, if you'd like the default to be English, but you want messages in, let's say, Swedish, then you're PG_INITDB_OPTS would look like so: PG_INITDB_OPTS="--locale=en_US.UTF-8 --lc-messages=sv_SE.UTF-8"

A complete list of language and character encoding supported by the server can be found in the documentation, but your system must also support the respective languages and character encodings. Compare the output of to the encodings in the documentation.

You may change your encoding selections after you've installed PostgreSQL with the exception of two: LC_COLLATE and LC_CTYPE. To change the encoding used on those, you must start the installation over again.

Optional: Mask Packages
In order to keep your installation on the lighter side, you may want to ensure that only minor updates are allowed. An upgrade from 8.4.1 to 8.4.2 is guaranteed to be 100% compatible with no data corruption. However, an upgrade from 8.4.1 to 8.5 might not be. Minor updates fix bugs and security issues, so you'll definitely want them as soon as they're available.

An example:

As has been stated before, slotting will prevent the incompatible updates from happening in the first place. This is only a method to keep one major version installed on your machine.

Finalizing the Installation
To finish the installation:

Configuration
By default, PostgreSQL will only read configuration files within its own data directory, which in turn is within it's own slot. The data directory is located where specified in PGDATA.

So, from the examples above, you'll find all the configuration files in.

postgresql.conf
This is the main configuration file. The line that you may find of immediate interest is listen_addresses. This variable defines to which addresses PostgreSQL will bind. By default, only loopback devices and Unix sockets are bound; localhost and. Changing listen_addresses is not enough, though, to enable remote connections. There is another file that actually controls the connections, covered in the next subsection. The official documentation is fairly easy to understand and is exhaustive on all the settings available. It would behoove you to read that rather than it be covered here as some things may change, and this author wouldn't be able to clarify it any further.

pg_hba.conf
This file states who is or is not allowed to connect to the database and in which way a user may log in to the database.

Again, the documentation is quite exhaustive on the settings and what they all mean. There seems to be some misunderstanding, though, as to how host names are mapped to IP addresses.

From the example above you can see that both an IPv4 and an IPv6 IP address is mapped to localhost. When PostgreSQL refers to this file, it will grab the first match and use that as the address; in this case 127.0.0.1. When PostgreSQL parses this, it will match IPv6 formatted address as well, e.g. ::ffff:127.0.0.1. If, however, the IPv6 address appears first, then PostgreSQL will map to ::1 alone, and ignore all IPv4 formatted requests; ::1 is not the same as ::ffff:127.0.0.1. So, it is better to specify IP addresses alone in this file rather than to rely on to be ordered properly and it removes any doubt as to which IP addresses are allowed.

The postgres Group
In order for your users to make local connections via the Unix socket to the server, your users must be in the postgres group. Use to add user to the postgres group. Users not in the postgres group will be rejected with: Permission denied.

Wrapping Up
The only thing left to do is to start PostgreSQL, where *.* is the major version:

You can verify if PostgreSQL has started by tail'ing the log file, like so:

And you should see output like this: Example output of tail /var/lib/postgresql/*.*/data/postmaster.log

And, optionally, add it to start at boot:

pgAdmin III
pgAdmin III is a graphical utility for managing PostgreSQL.

Server Lacks Intrumentation Functions
This problem is easy to solve. What is difficult about it is finding the answer. What is required is an import from a file that already exists on the storage drive: adminpack.sql. To resolve this issue, run this command:

Obviously, change posgresql-8.3 accordingly to the version you actually have installed.

Note that with 9.1, this is no longer supported. Read this for further information.