Re: Installing PostgreSQL on OSX Server - Mailing list pgsql-general

On Jan 28, 2013, at 6:45 AM, Stephen Cook <sclists@gmail.com> wrote:

> Hello!
>
> I have convinced a client to use PostgreSQL instead of MySQL (hooray), which means it falls on me to install and
configureit. I'm planning on doing this from the command line (I have SSH access). 
>
> I have installed and configured PostgreSQL on Windows, FreeBSD, and a few Linux flavors, but never OSX. I have the
basicdirections (http://www.enterprisedb.com/resources-community/pginst-guide) and found a couple of articles / blogs,
butreally I'm not an Apple guy so I don't want to miss anything or screw anything up. 
>
> Is there anything I should watch out for? I have some wiggle room (this is a development server at first), but I'd
rathernot break anything. 
>
> uname -a returns: Darwin xxx.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011;
root:xnu-1504.15.3~1/RELEASE_I386i386 
> PostgreSQL version: Latest and greatest - 9.2.2
>
> Thanks!

You're not planning on using this in production, I hope? OS X is a very solid desktop OS, but it's server variant is
packedfull of weird and plain broken behaviour. 

OS X includes the postgresql clients and libraries, and OS X Server includes the postgresql server. You don't want to
usethe included postgresql server, or the included libpq and binaries, but you'll want to make sure that they don't
clashwith the version you're installing - for the server that's not too painful, but for the clients you'll want to
makesure that the PATH of all users is set up to find your installed versions of psql etc. before the ones in /usr/bin,
andthat they're linking with the right libpq.dylib, not the one in /usr/lib. "otool -L" is the OS X equivalent to ldd. 

OS X doesn't have readline installed, it has libedit. Libedit is poor compared to readline, and the OS X installed
versionof libedit was, for years, hideously broken such that tab completion would cause SEGVs. It might have been fixed
inthe latest releases, or it might not. It's worth avoiding anyway. 

If you'll be installing using the point-and-click enterprisedb installer it should take care of some of the issues for
you.If you end up installing from source you need to be aware that OS X is a dual-architecture system with fat binaries
andlibraries (for i386 and x86_64 on recent releases). Depending on what your developers are doing that may be an
issue.The usual way of building fat binaries doesn't work for postgresql, or didn't the last time I tried it; you may
needto build twice, once for each architecture, then glue the results together to make fat libraries. 

Also, on a non-postgreql note, you'll find that the OS X userspace, particularly when it comes to system administration
tools,is strange and scary compared to the unixalikes you've used. You create users with multiple dscl commands, not
adduser.Daemons are managed by launchd, not started from /etc/init.d. 

http://labs.wordtothewise.com/postgresql-osx/ has a few notes on building and installing from source that might be
useful.

Recent versions of OS X server (10.6 and later, I think) can be installed in VMWare, as long as the host is running on
Applehardware (so either VMWare Fusion or ESXi running on a mini) if you want to build a play / staging environment
whereyou can roll back snapshots. 

Cheers,
  Steve