The task was clear - testing new features, tools and other changes in the version 9 (more precisely in the first betaversion). As some of the new features (e.g. the long awaited asynchronous replication) are already thoroughly tested for a long time, Pavel recommended to focus on testing applications based on PostgreSQL and migration using pg_upgrade (formerly this was a separate tool known as pg_migrator, newly it's a contrib module - see for example this).

We (more precisely the other guys, as I haven't found any bug) have found one bug in PostgreSQL itself (inability to plan a rather simple query with a left join in a subselect), and several bugs in related tools (pgadmin on the OS X and pg_upgrade). So rather a successful testing.

I have used two projects based on PostgreSQL - scrumspace and pgmonitor, and rather than bugs I've noticed several rather unexpected hitches related to replication. I didn't have opportunity (and time) to investigate details of the hot standby mode, and I've planned to use it to collect statistics (in pgmonitor) on a hot standby to unload the primary database.

Unfortunately I've found this to be impossible for two fundamental reasons

• pg_stat_ and pg_statio_ tables are not replicated - those tables are specific for the cluster, so each cluster (primary and hot standby) has it's own private set of tables with data
• not each select is allowed on the hot standby - for example the "age(XID)" function returns "age of the transaction" and that requires to get "actual XID" which is not possible on hot standby

But those are not bugs, those are features - however this brings a quite interesting problem. If you use a hot standby to build a high-availability solution (if the primary database fails, it's automatically replaced by the hot standby), where should you collect the statistics from?

In general you should collect the statistics from all databases that are used to execute queries (i.e. if it's just a backup, you don't have to collect statistics from it). But how do you recognize the switch from primary to hot standby already happened? In the statistics there will be a "skip" (the hot standby has it's own copy of data). And how do you recognize there was a "restart" when the "pg_postmaster_start_time()" function returns server start time  (i.e. time of start in a recovery mode, not the time of switch from recovery mode)?

In general a successul testing event - hopefully there will be something like that soon ;-)