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).
PostgreSQL 9.0 changes the game. You can run queries on a database that isn't active (particularly a standby database that is applying WAL files). Now this feature becomes much more interesting. I can use monitoring tools with SQL-only access to find out extremely useful things about the state of the standby.
I have to say, of all the postgres extensions I've written, controldata had to be the simplest. Hopefully it is useful to someone other than just us.
Thursday, April 29. 2010 at 11:53 (Reply)
Out of date already for CVS HEAD already, I just changed the fields yesterday with the wal_level patch ;-)
Saturday, May 1. 2010 at 19:25 (Reply)
Joe Conway wrote one of these last month too: http://archives.postgresql.org/message-id/4B959D7A.6010907@joeconway.com
Monday, May 3. 2010 at 14:30 (Reply)
Why keep perpetuating the non-PGXS paths in Makefiles? It doesn't get you anything. Your makefile could be as simple as this:
Line
1 MODULE_big = controldata
2 OBJS = controldata.o
3 DOCS = README.controldata
4 DATA = uninstall_controldata.sql controldata.sql
7 PG_CONFIG = pg_config
8 PGXS := $(shell $(PG_CONFIG) --pgxs)
9 include $(PGXS)