> Simon has put a lot of time into Hot Standby and has followed the > pseudo-defacto community process from design through what he believes to be > near-completion; he can't be sure of completion until someone reviews his > work.
I think this is a fair critique. > Yet, albeit with almost no review from the committers, Simon has continually > worked through testing, revising his patches, and requesting information and > suggestions from the community. There really was not a lot of review from mid-October through the end of the year. That is partly because Simon was out of commission for about three weeks and did not respond (in particular) to several requests to separate ICfR from HS. That having been said, since this is such an important feature to so many people, I think it would have been better if more effort could have been put into doing what additional reviewing was still possible. However, since the turn of the year, it looks to me like Heikki has actually put quite a bit of time into reviewing and responding to issues. Still, I agree that if there's anything we should be putting our effort into as a community right now, it's this feature. If we got Hot Standby in the next release and everything else in the CommitFest got bumped, I think a lot of people would consider that a good trade (though probably not the authors of the patches that got bumped). For example, I would much rather see Tom revert the updatable views patch and work on this than spend the next week fixing updatable views. At a minimum, I think the following patches from the CommitFest wiki should be returned with feedback or rejected: 1. SE-PostgreSQL. We handled this one badly, but there's not enough time to fix it now. 8.5. 2. rmgr hooks and contrib/rmgr_hook. Reject because Tom and Heikki don't believe it's the right approach. Need better use cases. 3. Synchronous log-shipping replication. We handled this one well, but it's not in good enough shape. 8.5. 4. pg_upgrade script. I haven't heard much about this in a while... I am doubtful that it is production-quality, but maybe I'm wrong? 5. Reducing some DDL Locks to ShareLock. No activity in a long time, no time to wait for this to be finished. 8.5. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers