What does it mean to be a database administrator? It means more than just respecting data in a room full of engineers and analysts that do not -- it means bending them to your will and making them respect it, too. It means knowing when people's concept of sacrosanct data integrity and consistency can be thrown out the window and letting those people know that, this time, they can cope with inaccuracy or volatility.
Hey you! PostgreSQL process running a query over there... Yeah you. What's your search path? Hello? Why aren't you listening to me? Oh, just because you are busy running queries for someone else for hours means you don't have to take some time to answer my question? Apparently, that's a good enough excuse. You, yes you process ID 18883, need to respect my authority. # echo '*postgres`namespace_search_path /s' | mdb -p 18883 0x9d5420: noit_a29_n625680_noit, stratcon, public I done told you.
Like many database, PostgreSQL stores critical (minimal) state about the database in what is called a "control file." This control file has valuable information in it that speaks to backups, checkpoints, block sizes, etc. PostgreSQL ships a tool called pg_controldata to dump this file's values in human-readable form. I've been frustrated in the past that you can't see all these values from within a PostgreSQL SQL session. At some point in the past I got in an argument about the usefulness of such a feature and I pretty well lost that argument: a postgres control file on an active database doesn't really show you (much) useful information and you really need it when the database is off (which is what pg_controldata provides).
This past week I had the privilege of presenting along side many distinguished speakers at this year's PostgreSQL Conference East 2010 in Philadelphia, PA. I presented PostgreSQL: meet your queue which was received even more warmly than I had anticipated. I really think that cueing your database to publish over AMQP is the bees knees and it turns out I wasn't alone!
So, it turns out that being stranded in an airport can lead to some productive output after all. I've hacked together an AMQP extension for PostgreSQL. If you don't know what AMQP or PostgreSQL are, stop reading. One thing I've needed to do for a while is be able to submit a message to a message queue from within a PostgreSQL transaction. However, obviously (because we run a real database here), if the transaction aborts I'd rather not have those messages sent.
PostgreSQL has pretty awesome date/time functionality. I’ve used a lot of database and the functionality and thoroughness of the treatment of dates and times (and particularly timezones) is unparalleled. As much as I’m impressed with it, I knew there would come a time where the outcome of all that cleverness would backfire. Recently, I was doing some data partitioning. I split a couple of largish (approximately billion row) tables up into month segments.
I recently attended dtrace.conf(08), which was a blast, but I left that conference with a single thought and it has been reinforced since. Everything should be dtrace enabled. While it is true that using DTrace you can introspect just about everything in the system, the pid provider (used to trace inside user-space applications) requires the user to to know the code of the application. A full system "in-flight" has too many different apps running for me to keep all of their code-bases in my head.
- OLDER POSTS
- page 1 of 3