On Jan 28, 2013, at 6:45 AM, Stephen Cook <sclists@xxxxxxxxx> wrote: > Hello! > > I have convinced a client to use PostgreSQL instead of MySQL (hooray), which means it falls on me to install and configure it. 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 basic directions (http://www.enterprisedb.com/resources-community/pginst-guide) and found a couple of articles / blogs, but really 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 rather not 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_I386 i386 > 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 packed full 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 use the included postgresql server, or the included libpq and binaries, but you'll want to make sure that they don't clash with the version you're installing - for the server that's not too painful, but for the clients you'll want to make sure that the PATH of all users is set up to find your installed versions of psql etc. before the ones in /usr/bin, and that 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 version of libedit was, for years, hideously broken such that tab completion would cause SEGVs. It might have been fixed in the 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 and libraries (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 need to 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 Apple hardware (so either VMWare Fusion or ESXi running on a mini) if you want to build a play / staging environment where you can roll back snapshots. Cheers, Steve -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
