'''If you are using one of these installers, or maybe a maintainer:''' Feel free to fill in missing information! Thanks.

'''If you are using one of these installers, or maybe a maintainer:''' Feel free to fill in missing information! Thanks.

−

= Why the following columns in this table? =

+

= If you want to save your data before you upgrade... =

+

+

Do not rely on your installer to take care of your data for you. Definitely do the following:

+

+

* Figure out where your data directory is. See '''Data Directory Locations''' below, or use <code>ps -auxwww | grep -i postgres</code> to find the Postgres process that's running - the path to your data directory is often right there in the process description.

+

+

Then:

+

* Make a copy of this data directory and store it somewhere safe, and/or

+

* Dump the data out of your running postgres instance with <code>pg_dump</code> and <code>pg_dumpall</code>

+

+

See the [http://www.postgresql.org/docs/current/static/backup.html PostgreSQL documentation on backups] for more information.

+

+

= Why do we have these columns in this table? =

Here's why the columns included in the table below matter:

Here's why the columns included in the table below matter:

Revision as of 02:19, 14 November 2012

Contents

Why create this document?

There are a number of Mac OS X installers, each with it's own idea of where software and data should reside. Below is a guide to help developers and users figure out where their data is, and which installer they might have used.

If you are using one of these installers, or maybe a maintainer: Feel free to fill in missing information! Thanks.

If you want to save your data before you upgrade...

Do not rely on your installer to take care of your data for you. Definitely do the following:

Figure out where your data directory is. See Data Directory Locations below, or use ps -auxwww | grep -i postgres to find the Postgres process that's running - the path to your data directory is often right there in the process description.

Then:

Make a copy of this data directory and store it somewhere safe, and/or

Dump the data out of your running postgres instance with pg_dump and pg_dumpall

Why do we have these columns in this table?

Here's why the columns included in the table below matter:

Version: Major versions of PostgreSQL must be upgraded with either pg_upgrade or pg_dump. Some versions require version-specific upgrade steps to be taken as well, which pg_upgrade or pg_dump will not execute for you.

Binary location: In order to start Postgres from the command-line (aka Terminal), use pg_upgrade or use command-line psql you will need to know the path to your Postgres binaries. This is especially important because the paths used by each of the installers are wildly different, and not included in your UNIX environment PATH settings.

Data directory dilocation: To use pg_upgrade, you must know where your data is located. This is also important if you are backing up your data - some people do not back up a directory like /usr/local, assuming that only re-installable information is in that directory. If you are using homebrew, this is a bad assumption.

Startup script location: To run pg_upgrade, you must be able to stop the running Postgres instance. On MacOS X, that probably means using launchctl and pointing it at the plist that controls your Postgres daemon.

Default LC_COLLATE setting: LC_COLLATE is set by initdb, which is how you create a new Postgres cluster in your data directory. Most installers take care of this for you, but different installers use different LC_COLLATE values. This is not entirely the installers' fault, as opinions about what should be the default value changed within the Postgres project itself. However, because different installers use different values, pg_upgrade will fail. This sucks for the user. If you specified either a collation or an encoding (typically with initdb -E UTF8) then this value may not affect you.