Postgres Open 2013

The 3rd annual Postgres Open conference started off with a keynote by a familiar face to the Python community, Jesse Noller. The focus of the keynote resonated with the ideals Six Feet Up has focused on; namely that the power of open source is the community that is built. This is what has been so exciting about the Python community. Whatever your problem domain, there is bound to be a thriving group of developers working on it.

The conference has many good talks lined up, leaving the painful choice of what to see in person. The list of presentations with links to slides is available on the Postgres wiki:

Common Themes

Some topics were discussed in several of the presented talks. For example:

• Taking advantage of the latest Postgres features
  • JSON
  • Replication
• Improvements to Foreign Data Wrappers
  • Writable FDWs
  • postgres_fdw

Highlights

Three talks I attended stood out:

Sane Schema Management with Alembic

It is always good to see how nicely Python and Postgres combine. Alembic is a Python package written by the author of the excellent SQLAlchemy database toolkit. It allows you to generate migration paths between versions of your database schema. We are heading into a phase of our Pyramid application Speak Friend that will require schema management, so this topic was quite well timed. Selena Deckelmann discussed the lesssons learned while trying to manage the schema powering Mozilla's Crash Stats app, Socorro.

Secure your webapp passwords in PostgreSQL

Magnus Hagander has given variations on this talk a few times. It is a very good strategy for handling sensitive data in your database, using the shadow mechanism used by many forms of Unix operating systems to protect user account passwords. I will be using several ideas from this presentation to improve how Speak Friend handles user password hashes.

Replication Refresh

Simon Riggs did a very good job covering the basics of what replication is, and how Postgres implements it in various forms. The most important aspects are probably that replication in Postgres is for the entire cluster of databases in an instance, and that the replication connection needs to be continuously available. There are two main forms of replication in Postgres:

1. Asynchronous
   • In this mode, changes will appear on the master before they appear on any of the slaves. The order they appear on slaves is also not deterministic.
2. Synchronous
   • In this mode, changes will first appear on the synchronous slave, and then be visible on the master.