Sunday, September 23, 2012

PostgreSQL packaging on Mac OS X is a mess

It appears to me - based primarily on what I see on Stack Overflow rather than direct Mac use experience - that PostgreSQL packaging on Mac OS X is a real mess.

There are at least four widely-used competing package systems:

Fink and MacPorts packages also exist, but seem to have either fallen into disuse or "just work" so I don't see breakage reports about them.


This makes supporting PostgreSQL on Mac OS X really painful. I'm not the only one who thinks so, though I don't agree with the solution proposed in that post.

I see *daily* questions about Pg on Mac OS X on Stack Overflow's PostgreSQL tag, usually related to installs not working, conflicts and PATH problems caused by multiple installs, Mac OS X upgrades (or sometimes just minor updates) breaking things, etc.

The problems don't boil down to a simple and common set of causes. There are launchd problems, PATH problems both at runtime (wrong psql) and build time (wrong pg_config), library path problems causing the wrong libpq to be found, endless different kinds of Ruby/Rails problems with the pg gem, etc. The #1 cause seems to be updates to Mac OS X, and the #2 multiple copies of PostgreSQL on one system without proper PATHs set up.

The group of users with the most problems appears to be Ruby/Rails people having issues compiling the `Pg` gem and connecting to the right version of Pg. How much of that is simply that Rails is popular and often used by inexperienced people is hard to guess.

The second big problem appears to be people who install several different packagings of PostgreSQL on one system and get exceedingly confused. See this recent SO question for just one example. Even uninstalling is complicated, as the user has to know what they installed and how before they have a hope of uninstalling it, leading to SO questions like this. Not that Linux is much better from the uninstallation standpoint, going by all the problems new users on Ubuntu/pg_wrapper systems seem to have purging and clean-installing Pg.

My question is: What can we do about all this? Can Pg proper improve this situation? Why aren't people using the EnterpriseDB installer? Or are they, and we just see problem reports from the Homebrew and Postgres.app people? Is this just "life on Apple" where Apple might break any non-Apple software on the machine and you have to put up with it? Or are these various Pg packagings doing things wrong, things that can be fixed so that Apple updates stop breaking them?

Should we be pushing Apple to run their bundled PostgreSQL on a different port, so they don't break people's reasonable expectation to be able to install Pg and run it on port 5432?

Is the answer documentation - or, more likely, will people just not read it? Do the various installers need to check for other Pg installs and warn the user?

(A related question I want to write more about soon is the problem currently faced by people who want to bundle Pg in their application installers. Many of them are using the EnterpriseDB installer in silent mode, but I think that's quite harmful as it'll leave users with a PostgreSQL install they don't know the passwords for and didn't set up themselves. If they go to install Pg themselves later problems will arise.)

7 comments:

  1. I use MacPorts, and it's great. Always has up to date releases of postgres, and has all the supported versions available (8.3.x to 9.2.x) to be installed in separate directories if you need to use different versions. Highly recommended!

    ReplyDelete
    Replies
    1. Good to know that MacPorts is alive and well. I used it last time I did much on a Mac a while ago.

      I'd be really interested in seeing if the Mac-using Pg community can get together on the Pg wiki and start writing up information on available Mac packagings of PostgreSQL, how to install and uninstall them, where their datadir/config files go by default, how to manage conflicts between them, how to compile software against them, etc.

      Right now that info is usually scattered across way too many random forums, implicitly assumes you're using one particular packaging, and is out of date.

      Delete
  2. I am using Postgres.app myself and it works just fine without any issues. Just that you cannot build stuff against it but there is already a feature request for that iirc

    ReplyDelete
    Replies
    1. It seems that any individual packaging usually works fine for someone who's experienced enough to know what the PATH and library path is, that you need to uninstall a program not just delete bits of it, etc.

      The main issue seems to be people who follow "recipes" on random articles, landing up installing Postgres.app from Heroku, then homebrew postgres when they follow instructions to compile the Pg gem for Ruby, then that breaks so they try to install the EnterpriseDB installer after half-deleting the homebrew version...

      What I'm interested in tackling - or encouraging the Mac postgresql community to tackle, as I don't use a Mac - is to find ways to make it harder for new users to get into this mess, and easier for them to get out of it. Even a "how to completely un-install all known packagings of PostgreSQL from your Mac" article would make a huge difference - but it requires someone with a Mac to write it.

      I'd do it, but time's an issue, and more importantly Apple won't let me install Mac OS X on a virtual machine, so it's on the very bottom of my can-be-bothered-to-support list.

      Delete
  3. I tried installing using EnterpriseDB installer for Mac. Seemed to work fine but then I couldn't get the PostGIS extension installed via stack builder. So, then I tried Homebrew...a migraine or two later I had it working.

    ReplyDelete
  4. I use MacPorts, and can confirm that your hunch regarding "just works" is correct w.r.t. PG, including cleanly supporting both 8 and 9 concurrently.

    ReplyDelete
  5. Agreed. I created this disambiguation wiki page to try and capture how different they all are: http://wiki.postgresql.org/wiki/Installers/Mac_OS_X

    ReplyDelete

Captchas suck. Bots suck more. Sorry.