Following on the smashing success of PostgreSQL Conference West, PostgreSQL Conference West, The PostgreSQL Conference for Developers, End Users and Decision Makers, is being held at the Hotel Pennsylvania, in New York City from March 22nd through 25th 2011. Please join us in continuing to make this the largest PostgreSQL Conference series!

      * General PostgreSQL: 
              * Administration 
              * Performance 
              * High Availability 
              * Migration 
              * GIS 
              * Integration 
              * Solutions and White Papers 
      * The Stack: 
              * Python/Django/Pylons/TurboGears/Custom 
              * Perl5/Catalyst/Bricolage 
              * Ruby/Rails 
              * Java (PLJava would be great)/Groovy/Grails 
              * Operating System optimization
                (Linux/FBSD/Solaris/Windows) 
              * Solutions and White Papers 

"Slony-I is undoubtedly our most popular replication tool. It supports Master-Slave High Availability Replication. However, there are a number of other solutions, such as dbMirror, eRServer, pgPool, C-JDBC, and the proprietary Mammoth Replicator, all of which are in wide use because they solve different replication problems than Slony-I does. Replication is not a single solution for a single problem; it is several solutions for a wide array of different problems. That's why no one replication tool will ever be the "default" replication for PostgreSQL."

I believed well before then it was a fallacy and a bad community decision to not put support behind a single, integrated solution. I also believe it has been one of the single most important policy failures of the .Org community and has lead PostgreSQL to grow much more slowly than it otherwise could have.

From a business standpoint it opened the door for many other solutions, a lot of learning experiences and a lot of professional services consulting (Thank you: Slony). It also opened the door for the only solution to look at being integrated into Core. Mammoth PostgreSQL Replicator (Replicator).

Replicator opened the door for CMD in many ways. Although it was never a huge commercial success we did have early customers (Cisco) and there was quite a few deployments over time. Eventually, we Open Sourced Replicator hoping to generate some external interest, and although quite a few hackers talked to me about participating, none of it actually materialized into anything useful.

To this day, nothing can touch the usability of Replicator for PostgreSQL replication. It is the easiest to configure, the easiest to run, the easiest to manage. Alas that is not enough, as we needed to re-architect to eliminate the one single point of failure (as well as some other issues, crash safety I am looking at you). Further with the emergence of the Hot Standby technology that is in 9.0, the need for Replicator has become even less.

Although there were design decisions originally made that were incorrect, I still believe that the overall architecture of Replicator was sound. Implementation, perhaps not but architecture yes. I also believe that the in development version (1.9) would have been a game changer as a whole. Unfortunately we were not able to execute for a number of reasons that don't really matter anymore.

Everyone who worked on replicator should be proud of what they did. It should be looked on as a learning experience. We built something, nobody else did, even now. We built integrated and flexible PostgreSQL replication. Was it perfect? No. Should we have open sourced it sooner and tried harder to integrate it into the community? Probably. Were there design decisions that should have been different? Yes. Were there components we should have changed (MCP SPOF)? Yes.

Of course, we can say all of that about the current state of PostgreSQL. Let alone Replicator, Slony or any other project. Just read -hackers. We are not perfect, but our team did something good.

It took until 2010, 7 years? after Replicator first released for the community to figure out they were wrong. We were pioneers for PostgreSQL and our team should be proud of that.

1. http://archives.postgresql.org/pgsql-advocacy/2004-11/msg00063.php

Command Prompt has provided PostgreSQL support, development, and hosting since 1997. We are looking for another person to join our stellar group of PostgreSQL systems experts.

We seek someone who has a deep knowledge of at least one UNIX-like system, and who knows how to manage heterogeneous systems well. You can demonstrate strong skills in basic systems administration. You have a clear understanding of how to administer several systems that are mostly the same, but that have small local differences. If you do not feel comfortable saying, "I'm not familiar with that in your environment," then reading the man page, and coming back with a test plan for deployment that will reveal problems with your strategy, this is not a job for you. The ability to imagine, propose, test, and deliver perfectly-integrated and easily-maintained solutions to users' problems is the key to success in this position. You work well in a team: you don't have to work 24 hours a day, because other people can always log into any system you maintain and know where everything is, how it got there, and how to add new things if they're needed.

You must know basic PostgreSQL administration, and understand how to set up, operate, and tune Postgres in elementary ways, such as installing from a package manager. You do not have to be a PostgreSQL guru, but if you are, that is a bonus.

You have systems administration capability with shell scripts, as well as either Perl or Python. As well as understanding (or quick to pick up) technologies such as DRBD and LVM2.

You have an interest in working on varied projects that use varied (and sometimes legacy) technologies.

Command Prompt is a professional services company. You will be interfacing with customers, therefore customer service and professionalism is key.

Command Prompt employees usually work from their home offices. The position normally requires minimal travel. For this position, the successful candidate will be able to communicate effectively in English. English as a spoken second language is fine as long as the written skills are clear and effective.

This is a remote position and does not require residence in the United States.

Applicants should send a resume to Joshua D. Drake, jd(at)commandprompt(dot)com, with the words "intermediate administrator" in the Subject line. Please include any text by way of a cover letter in the body of your email and not as a separate attachment.