Upgrading Brew-Installed PostgreSQL on OSX

Here’s the tl;dr: If you want to see the full instructions, look further down:

new_pg=9.3.3 #CHANGE THIS!!
psql postgres -c "select version()" #make sure you've still got the old version running
pg_dumpall > pg_backup.sql
launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
sudo mv /usr/local/var/postgres /usr/local/var/postgres.old
sudo brew switch postgresql $new_pg
initdb /usr/local/var/postgres -E utf8
launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
createdb #run this if you get an error when trying to import the dump below
psql < pg_backup.sql
psql postgres -c "select version()" #make sure you've got the new version running
psql -l #see if all of your databases are still there
vacuumdb --all --analyze-only #optional
sudo brew cleanup postgresql #this will remove the older versions brew installed
sudo rm -rf /usr/local/var/postgres.old #if you're feeling really confident / don't care

Somehow, whenever I sit down to do some tinkering on my computer, it seems like a new version of PostgreSQL is ready to be installed via Brew. Since I always forget what the steps are to upgrade between major versions of Postgres, I figured I’d throw it into a blog post. Mostly for my own pleasure, but others might find it useful, as well.

First, you realize that Brew is installing the new version, and you panic! “What about my data!?” you might say. Don’t worry, the old version is still running. You can verify this by opening psql, and running select version(). You should see your old version. We need to dump your databases so that you can restore them to your new version:

pg_dumpall > pg_backup.sql

Now, we need to stop the old version, move the old cluster to a safe place (in case we need to revert for some reason), tell brew we want to use the new version as the default, and start the new one. It sounds complicated, but it’s not:

launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
sudo mv /usr/local/var/postgres /usr/local/var/postgres.old
sudo brew switch postgresql 9.3.3
initdb /usr/local/var/postgres -E utf8
launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

Now, restore the dump into the new version:

psql < pg_backup.sql

If you get an error saying that the database (usually named the same as your login) could not be found, just crate it, using the following command:

createdb

You should now be good to go! As a bonus, if you get this error (which I did)

➜ ~ psql
dyld: Library not loaded: /usr/local/opt/readline/lib/libreadline.6.2.dylib
Referenced from: /usr/local/bin/psql
Reason: image not found
[1] 39772 trace trap psql

You either need to install readline from brew, or it needs to be re-linked:

sudo brew install readline
sudo brew link --force readline

If you had to install readline, then you will need to re-install postgres:

sudo brew reinstall postgresql

SELECT * Analogy

The DBAs at the company I work for sent out a mass email this morning “reminding” developers that using SELECT * is a bad idea. One of my friends, who usually asks me about database questions was confused about one part of the email:

If implementing these changes for an existing application, the percentage decreases will be off the time to process columns and not necessarily off the total currently used by the SQL statement.

And I came up with what I thought was a pretty good analogy:

Let’s pretend the database table is a grocery store, and you need to buy ingredients so you can bake a cake.

“SELECT *” would be like taking every single product in the store home and then figuring out which ingredients you actually need to make a cake.

Selecting individual columns would be taking your recipe with you and getting only the ingredients you need.

It still might take you a while to go through the store, especially if it’s one of those huge mega-marts (a.k.a, a really big query with lots of joins) to find the ingredients you need, but only getting the products you need will make things a lot faster when you get home.