From PostgreSQL wiki

Revision as of 22:01, 13 November 2012 (view source) Selena (Talk | contribs) (→Known Installers) ← Older edit		Revision as of 22:01, 13 November 2012 (view source) Selena (Talk | contribs) Newer edit →
Line 94:		Line 94:
	|		|
	|}		|}
		+
		+	= Resources =

---

Revision as of 22:01, 13 November 2012

Contents 1 Why create this document? 2 Why the following columns in this table? 3 Known Installers 4 Resources

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.

Why the following 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 manually start Postgres, 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.
• 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.

Known Installers

Installer	Version	Binary location	Data directory location	Startup script location	LC_COLLATE setting
Built-in PostgreSQL on Mac OS X Lion	9.0.x		/var/pgsql	/System/Library/LaunchDaemons/org.postgresql.postgres.plist
EnterpriseDB Mac OS X 1-click Installer	9.2.x	/Library/PostgreSQL/9.2	/Library/PostgreSQL/9.2/data	/Library/LaunchDaemons/com.edb.launchd.postgresql-9.2.plist	C
EnterpriseDB Mac OS X 1-click Installer	9.1.x				C
EnterpriseDB Mac OS X 1-click Installer	9.0.x				C
EnterpriseDB Mac OS X 1-click Installer	8.4.x				C
Postgres.app	9.0.x
Postgres.app	9.1.x	/Applications/Postgres.app/Contents/MacOS/bin	~/Library/Application\ Support/Postgres/var
Postgres.app	9.2.x
homebrew (aka 'brew install postgres')	9.2 (as of Sept 2012)	/usr/local/bin (binary named postgres)	/usr/local/var/postgres	/Library/LaunchAgents/homebrew.mxcl.postgresql.plist	UTF-8
macports

Resources