Share Tweet Share





By now, the news that Hot Standby won’t make it into 8.4 has rippled through the PostgreSQL community. A lot of people are asking me what happened. Around seven months ago, the PostgreSQL Core Team caused a stir in the OSDB community by declaring that simple built-in replication based on log shipping was going to be a priority for future PostgreSQL development. This was unusual, since the Core Team doesn’t normally try to set development direction … we just decide when the releases will be, and settle any long-running arguments. A lot of people got excited about this, mostly because they didn’t read the part where we said “for version 8.5, out in 2010”. We knew how hard the problems around having reliable, simple, low-administration replication are, and didn’t expect to solve them in the 4 months we had to work on 8.4. People had started work, but we knew it was unlikely to be completed in time. What we have to do includes:

Making queryable slaves (Hot Standby)

Making the slaves lag behind the master less

Creating the option for slaves to be transactionally identical to the master (Synch Standby)

Adding management tools & easy setup

Dealing with VACUUM and other file-based operations for all of the above.

As expected, the NTT Open Source team working on Synch Standby ran into some unexpected issues and it became clear by December that extensive refactoring was required, and Synch Standby wasn’t going to work for version 8.4, which we wanted to ship by May. However, hacker Simon Riggs, the original contributor of PostgreSQL PITR, jumped at the task and put in a heroic effort to complete very-asynchronous hot standby for 8.4. For quite a while, it looked like we would have our first level of Hot Standby in 8.4, which everyone got excited about. But no patch is final until committed. Committer Heikki Linnikangas and Simon ran into quite a few issues and corner cases, particularly involving subtransactions, and by last week Heikki didn’t feel like they were anywhere near having a robust enough version to go in. So, we decided to postpone Hot Standby to version 8.5. Yes, a lot of people were disappointed, none of them more than me (well, except maybe Simon). But, making hard decisions to postpone features which aren’t quite ready is how PostgreSQL makes sure that our DBMS is “bulletproof” and that we release close to on-time every year. Our own history with the Windows port, as well as our colleagues at Sun/MySQL, have amply demonstrated the consequences of putting specific features ahead of the overall development schedule: your software is either late, or buggy, or both. It’s not like 8.4 will lack features, after all … it already includes windowing functions, recursive queries, new performance monitoring tools, greatly reduced VACUUM requirements, better cache management, and lots of other great stuff. And … when we have the full set of standby modes and tools for version 8.5, they will not only be useful and cool, they will be … to quote another DBMS … “unbreakable”. It’s the only way we know how to do things in the PostgreSQL Project. (P.S. If you’re looking for an easy-administration replication tool for PostgreSQL right now, londiste and pgPool2 have both matured quite a bit, and there are new Slony easy-admin tools.)