Apt/FAQ

General Questions

What's the difference between the PostgreSQL packages provided by Debian/Ubuntu and by the PGDG apt repository?

Pretty little, actually. The PGDG packages are built from the same source as the Debian packages (Ubuntu is using the same source for the PostgreSQL server packages as well). We try to follow Debian unstable's versions as close as possible, i.e. the packages available here are the same, just rebuilt with a ".pgdg" appended to the version number. We are also using the same postgresql-common infrastructure packages.

Should I use Debian/Ubuntu's packages, or the PGDG packages?

Debian and Ubuntu only ship one PostgreSQL server version per release. For example, there is only PostgreSQL 8.4 in Debian Squeeze/6.0. If that is the version you want, use it. There is no real difference. If you want a different PostgreSQL server version, use the PGDG packages.

Same goes for extension module packages, except that we are updating to new upstream versions earlier (following Debian unstable), while Debian/Ubuntu will only accept patches for critical problems in a released distribution.

What about Debian backports?

[Debian backports] provide newer package versions for released distributions, similar to what the PGDG apt repository does. The scope of the backports archive is strictly limited to testing -> stable, and stable -> oldstable backports, though. The PGDG apt repository provides a broader range of available packages, and Debian version/PostgreSQL version combinations than what would be possible to provide on backports.

Similar to the previous FAQ question, if the package you want is available on backports, there is nothing wrong with using it.

Are these packages ready for production?

As said above, these packages are identical to what Debian/Ubuntu are releasing. So yes, these packages are recommended for production use.

What's pgapt.debian.net?

pgapt.debian.net was the old location of this repository, which was shut down in January 2013.

Technical Questions

How do I dist-upgrade?

Just update your sources.list entries, and use your favorite package tool.

When compiling packages for several distributions, we append different suffixes to the package version numbers to make sure, upgrades work. Debian Squeeze packages have ".pgdg60+1" appended, Wheezy packages ".pgdg70+1" and so on; likewise ".pgdg12.4+1" for Ubuntu Precise. (Sid packages have ".pgdg+1", which sorts after all the others in Debian's version number scheme.) This makes sure packages from the old distribution you used will be properly replaced by packages from the new distribution when you do a dist-upgrade.

Where is the "stable" distribution?

We prefer to only use codenames (squeeze, precise, ...) for distribution names. We run a different repository from Debian, so we would never be able to update the stable/oldstable/testing symlinks at the very same time when a new Debian release comes out, and there would be a time window where users would be seeing an inconsistencies. (Also, it is usually better to use codenames in sources.list even for Debian distributions, because then the user decides when it is time for upgrade.)

I am using a non-LTS release of Ubuntu

Non-LTS releases of Ubuntu are only added to the repository if the packages from the latest LTS release are incompatible with the release in question. Using the latest LTS release instead generally works, unless library dependencies cannot be fulfilled, in which case we will provide updated packages for the non-LTS release.

I want only specific packages from this repository

Per default, the PGDG repository will have the same "pinning" priority as your Debian/Ubuntu repositories. This means your existing PostgreSQL packages will be replaced with versions from this repository, because they have greater version numbers. If you do not want this, you need to configure pinning (see apt_preferences(5) for details).

Create the file /etc/apt/preferences.d/pgdg.pref:

Package: *
Pin: release o=apt.postgresql.org
Pin-Priority: 200

The default priority for repositories is 500, so 200 will lower the PGDG repository priority enough such you don't get packages automatically installed from there, but once you have packages installed, they will keep getting upgraded to newer versions from the PGDG repository.

You can check your setup using the apt-cache policy command to see if "200" shows up in the output:

$ apt-cache policy postgresql-9.1
postgresql-9.1:
  Installed: 9.1.8-1.pgdg70+1
  Candidate: 9.1.8-1.pgdg70+1
  Version table:
 *** 9.1.8-1.pgdg70+1 0
        200 http://apt.postgresql.org/pub/repos/apt/ wheezy-pgdg/main amd64 Packages
        100 /var/lib/dpkg/status
     9.1.8-1 0
        500 http://ftp.debian.org/debian/ wheezy/main amd64 Packages

I want libpq5 for version X, but there is only version Y in the repository

libpq5 is compatible with older versions, so there is usually little reason to use a specific version. (psql requires at least the version corresponding to its own version, most other software does not really care.) For that reason, we ship the libpq5 package built from the latest stable PostgreSQL server version in the main archive component.

If you really want to use a different version, the packages are available in separate archive components named after the PostgreSQL major version. Append that version after "main" in your sources.list. For example, if you wanted 9.0's libpq5 on Debian Squeeze, use this:

deb http://apt.postgresql.org/pub/repos/apt/ squeeze-pgdg main 9.0

Note that the other libpq5 package will still be visible in the "main" component, so you will need to configure pinning or set that package on hold to prevent apt from trying to upgrade to the newer version.

I want to try the beta version of the next PostgreSQL release

WARNING: The data format may change between beta releases. Be prepared to pg_dump the database contents before you upgrade the package to a newer beta or to a final release. Check the release notes before upgrading.

We ship packages for beta and RC releases, but like in the previous FAQ entry, you need to add the 11 component to your /etc/apt/sources.list.d/pgdg.list entry, so the version 11 packages will be available for installation:

deb http://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main 11

Development snapshots

WARNING: Development snapshots are meant for testing purposes only, and the catalog version will change frequently. Don't store any data you cannot afford to lose.

Development snapshots of postgresql-11 are being built every 6 hours, directly from git. The packages are available for amd64 only, for the following distributions: sid-pgdg-testing, stretch-pgdg-testing, jessie-pgdg-testing, xenial-pgdg-testing, and trusty-pgdg-testing. You need to add a sources.list entry including the 11 component, e.g. for xenial:

deb http://apt.postgresql.org/pub/repos/apt/ xenial-pgdg-testing main 11

or, slightly more generally:

 sudo add-apt-repository "deb https://apt.postgresql.org/repos/apt/ $(lsb_release -s -c)-pgdg-testing main 11"

After updating from an alpha or beta release I get an error about CATALOG_VERSION

After upgrading from an alpha or beta package, I get an error like:

The database cluster was initialized with CATALOG_VERSION_NO X, but the server was compiled with CATALOG_VERSION_NO Y.

This is because the PostgreSQL data format can change between alpha releases - and occasionally even between beta releases if there's a really pressing need.

If you need to access the old data, you will need to use the package version you were running before, and use pg_dump or pg_upgrade. The necessary binaries should have been saved in /var/tmp/postgresql*. Alternatively, look for the old packages in your /var/cache/apt/archives.

What are the testing distributions?

We have distributions squeeze-pgdg-testing, precise-pgdg-testing, sid-pgdg-testing, ... which receive all updates before they are promoted to the "live" distributions. These are not meant for production use, but you are welcome to use them and help debugging and testing the packages. Please join the mailing list or the IRC channel. The distributions have a lower apt priority by default, you will have to set up pinning (e.g. with priority 500) if you want them to be used automatically.

Can I mirror the repository?

For a full mirror of some or all distributions, we suggest to use debmirror. For mirroring just a subset of packages, reprepro offers the ability to "pull" packages from remote repositories.

Where are older versions of the packages?

The *-pgdg distributions only contain the most recent version of each package. Older versions are available in the morgue at http://atalia.postgresql.org/morgue/.

(There is no dists/ structure, and the provided Packages.xz and Sources.xz files contain all packages for all distributions, users will need to choose the correct files manually.)

GPG error: invalid signatures

If you are getting errors from apt-get update like:

W: A error occurred during the signature verification. The repository is not
updated and the previous index files will be used. GPG error:
http://apt.postgresql.org squeeze-pgdg Release: The following signatures were invalid: KEYEXPIRED 1381654177

... you have an outdated copy of the repository key. In most cases rm /etc/apt/trusted.gpg.d/apt.postgresql.org.gpg will fix it by removing the second copy of the key. Use apt-key list to check.

systemd integration

The postgresql-common package contains systemd service files that handle starting/stopping/reloading the installed clusters.

Unfortunately, the systemd version shipped with wheezy is incompatible with the "reload" part of the service files. Upgrade to the systemd version in wheezy-backports to fix. (Users of jessie and newer Debian and Ubuntu versions are not affected, the systemd version there is recent enough.)