After three years of having our summers trumped by Jen pursuing her Masters degree, we decided to take a crazily overboard vacation to make up for it. As it happened, Hawaii won the coin toss, and Maui seemed a good start. We ended up tweaking our travel times just right and got a deal, so from June 14th to the 20th, the continental United States could no longer taint us with its relative banality.
And so, I’ve fallen off the planet once again.
It’s not exactly like nothing has been going on, It’s just that my unparalleled boringness was eclipsed by my aggressive laziness. My vacation in Hawaii—which I returned from a month ago—still remains woefully unchronicled. Instead, my precious hours have been consumed by gambling and collecting bellybutton lint. Except for a few minor items . . .
With the introduction of PostgreSQL 8.4, Bruce Momjian, a significant core developer, contributed a tool that can actually upgrade an entire database cluster in place. The time required is essentially only that necessary to copy the data files from the old installation to the new one. On a quick RAID system, this can be an order of magnitude faster than a dump/restore. The main drawback is similar to Slony: disk space must effectively be doubled for this upgrade method.
I was fighting with packaging some software at work, trying to produce a workable RPM package to replace the manually installed kludge currently polluting one of our servers, and discovered the --spec-only option to the bdist_rpm action.
Now, this particular option only makes sense since a spec file must be generated for bdist_rpm to work anyway, but I never thought about it. What it provides is an awesome shortcut to doing packaging slightly more complicated than merely relying on what bdist_rpm produces. Why? Because of the sdist action.
PostgreSQL can be both a beautiful thing, and an infuriating mess.
Occasionally I look through the logs on one of our database servers to see if I can’t optimize some queries. It’s good practice, and is an excellent way to monitor basic system performance by watching for queries that take longer than might otherwise be possible. Sometimes performance can be fixed by tweaking an index, or manually rewriting the query and convincing a developer to integrate the changes.