8.3 beta testing suggestions welcome - Mailing list pgsql-hackers

I've been lobbying management here for us to allocate some resources to testing 8.3 once it hits beta.  If it is
approved,it might happen on a time frame too short to get much feedback before the tests, so I'm throwing the question
outhere now: what would people like us to bang on? 
The box most likely to be used for the testing is a bit old, but still, it is SMP and we would be throwing real-world
trafficat it, so it should be of some value.  It has 4 2 GHz Xeon MP CPUs, 6 GB RAM, and a RAID controller with 256 MB
battery-backedRAM cache.  The 230 GB database would be sitting on a 407 GB RAID 5 array.  In addition to the PostgreSQL
instancethere would be two Java middle tiers running on the box. 
One middle tier is for modifying data based on transactions received from 72 source databases; this load is about 1
milliondatabase transactions on a typical work day, with an average of maybe 20 INSERT, UPDATE, and DELETE statements
pertransaction.  (We don't typically have many deletes.)  The other middle tier uses a login which only has SELECT
rightsto support our web site.  We have about 2 million web hits per day generating about 10 million database
transactions. We can play the actual HTTP requests from our log through a bank of renderers to get a real mix of
queriesfrom production. 
We're particularly interested in seeing what configuration changes we may have to make to achieve optimal performance
withthe checkpoints and background writer in the new release.  When we first went to PostgreSQL our biggest problem was
thatdirty buffers would accumulate in shared memory until a checkpoint, and then overrun the controllers cache.  This
wouldcause disk reads to queue up behind the writes, and queries which normally ran in a millisecond or two were timing
outat our renderers' 20 second limit.  The problem went away completely when we used a very aggressive background
writerconfiguration, to put the dirty pages in front of the OS file system right away, so that its algorithms and the
controllercache could deal with things before they got out of hand. 
We could run some tests with just the read-only web load, if that is useful, or push the update load alone.  We could
paceinput.  My guess is that the most useful tests would involve letting both run as fast as the machine can handle it
withvarious configurations and see what throughput and timeout counts we get. 
Any thoughts or suggestions welcome, particularly about what configurations to try.
-Kevin