Re: Hot Standby (commit fest version - v5) - Mailing list pgsql-hackers

Hi,

I found that no one is registered as hot standby reviewer.   I'd like
to review the patch, mainly by testing through some benchmark test.

Regards;

2008/11/2 Simon Riggs <simon@2ndquadrant.com>:
> Hot Standby patch, including all major planned features.
>
> Allows users to connect to server in archive recovery and run queries.
>
> Applies cleanly, passes make check.
>
> There's no flaky code, kludges or other last minute rush-for-deadline
> stuff. "It all works", though really for a patch this size and scope I
> expect many bugs. As a result I am describing this as "WIP", though it
> is much more than a prototype. All the code has been planned out in
> advance, so there's been very little on-the-fly changes required during
> final development. I'm fully committed to making all required changes
> and fixes in reasonable times. I will continue detailed testing over the
> next few weeks to re-check everything prior to commit.
>
> Initially, I would ask people to spend time thinking about this
> conceptually to check that I have all the correct subsystems and cater
> for all the little side tweaks that exist in various parts of the server
>
> When you test this, please do it on a server built with --enable-cassert
> and keep a detailed log using trace_recovery_messages = DEBUG4 (or 2-3).
>
> Code has been specifically designed to be performance neutral or better
> for normal workloads, so the WAL volume, number of times we take WAL
> locks etc should be identical (on 64-bit systems). The patch includes
> further tuning of subtransaction commits, so I hope the patch may even
> be a few % win on more complex workloads with many PL/pgSQL functions
> using EXCEPTION. Enabling the bgwriter during recovery seems likely to
> be a huge gain on performance for larger shared_buffers settings, which
> should offset a considerable increase in CPU usage during recovery.
>
> Performance test results would be appreciated
> * for normal running - just to test that it really is neutral
> * for recovery - if query access not used is it faster than before
>
> Points of significant note for detailed reviewers
>
> * Prepared transactions not implemented yet. No problems foreseen, but
> want to wait to see if other refactorings are required.
>
> * Touching every block of a btree index during a replay of VACUUM is not
> yet implemented. Would like some second opinions that it is even
> required. I have code prototyped for it, but it feels too wacky even
> after Heikki and I agreed it was required. Do we still think that?
>
> * locking correctness around flat file refresh still not enabled
>
> * need some discussiona round how to handle max_connections changes
> cleanly.

-- 
------
Koichi Suzuki