Up until the last month or so, the development arc for PostgreSQL 9.1 was looking fairly humdrum. Quite a bit of good refactoring and some good general enhancements, but not a lot of sizzle. That seems to be changing now. Of course, in one sense, that's a bad thing: we're only three weeks from the end of the development cycle, and ideally it would have been nicer to have some of these big patches land just a little bit sooner. Still, I feel pretty good about the quality of what's been committed.
Monday, January 24, 2011
Thursday, January 20, 2011
Locking in PostgreSQL
Have you ever had one of those annoying problems where a query, or some kind of maintenance task such as vacuum, seems to hang, without making any discernable foreign progress, basically forever? If it's a foreground task, you typically think to yourself "oh, that's taking longer than normal" - but then you start to become suspicious as to whether anything's happening at all. You fire up top, or strace, or gdb, or iostat, or some combination of those tools, and eventually decide that, indeed, nothing is happening.
Tuesday, January 18, 2011
What Kind of Replication Do You Need?
As you probably know by now if you're a regular reader of Planet PostgreSQL, or if you've read the PostgreSQL 9.0 release notes, PostgreSQL 9.0 offers a much-improved form of built-in replication. In PostgreSQL 8.4 and prior releases, replication was possible via WAL shipping, but the delay between master and standby could be several minutes, or even longer, depending on configuration parameters. This delay has been essentially eliminated in PostgreSQL 9.0, which allows the write-ahead log to be streamed from master to standby as it's generated.
But it's still asynchronous replication - as opposed synchronous replication, which has been proposed for inclusion in PostgreSQL 9.1. If the master crashes just an instant after processing a COMMIT statement, the client will believe that the transaction has committed, but the slave won't know about it. If the slave is then promoted to become the new master, the transaction is gone forever.
But it's still asynchronous replication - as opposed synchronous replication, which has been proposed for inclusion in PostgreSQL 9.1. If the master crashes just an instant after processing a COMMIT statement, the client will believe that the transaction has committed, but the slave won't know about it. If the slave is then promoted to become the new master, the transaction is gone forever.
Friday, January 14, 2011
Why SQL/MED is Cool
One of the big patches that is in the works for PostgreSQL 9.1 -- and will hopefully but not for sure make the cut -- is a series of patches that implement basic SQL/MED functionality for PostgreSQL. What is SQL/MED and why should you care?
Tuesday, January 04, 2011
PostgreSQL 9.1: Big Patches
About three weeks ago, I wrote a blog post about the forthcoming end of the PostgreSQL 9.1 development cycle, and the many large and important features for which we have patches outstanding. Since we now have just 11 days to go before the beginning of the forth and final CommitFest, this seems like a good time to revisit the progress we've made. Here again is the list of features from my previous post:
Subscribe to:
Posts (Atom)