Re: Recovery Test Framework

Tom Lane wrote:
> "Christopher Browne" <cbbrowne(at)gmail(dot)com> writes:
> > On Mon, Jan 12, 2009 at 12:27 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> >> On Mon, Jan 12, 2009 at 5:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >>> In general, we have always regretted it in the past when we chose to
> >>> slip a release waiting for a specific feature...
> >>
> >> I don't recall such a time - though perhaps the last time it happened
> >> was before I was so heavily involved in the release process (ie. 7.x).
> >> What were the reasons for regretting it?
>
> > I seem to recall us deferring 8.1 (was it 8.1?) for a while on the
> > basis that we were waiting for [something I don't recall offhand].
> > The feature that we were *hoping* to get wound up dropped on the floor
> > because it just wasn't ready, even *with* the extra time.
>
> That's happened more than once, though my memory of details is fuzzy
> and I don't have time to troll the archives for them right now.
> Maybe Bruce can remember without a lot of searching. But our current
> policy of time-based releases (ie deadlines) is born of hard experience
> with the negative consequences of saying "we'll release when feature X
> is ready". The real killer disadvantage is that all other development
> tends to stop until X is ready, because no one can plan anything.

OK, I had to think about this one, and I didn't want to fan the flames
in the discussion either.

Basically, I have given up trying to track the many patches around
recovery, replication, and hot standby, and I have stated that to
several people privately. I have kept an archive of the active emails
about the topic:

http://momjian.us/cgi-bin/pgsql/pitr

Looking at the list on the commit fest wiki:

http://wiki.postgresql.org/wiki/CommitFestInProgress#Recovery.2C_Replication.2C_Hot_Standby

I think we should focus on the two simplest patches first,
"Infrastructure changes for recovery", and "rmgr hooks and
contrib/rmgr_hook" because those are probably the easiest to get
committed.

Based on comments from Heikki, I think "Hot Standby - queries during
archive recovery" can be committed, and in fact perhaps Heikki can do
the commit.

As far as "Synchronous log-shipping replication", there was only a hope
that would be completed in time for 8.4, and in fact trying to complete
it probably made completing the other patches harder. I think it is
time to focus on the first three patches I listed and accept that we are
not going to be able to complete synchronous log-shipping in time. I
think the code is just too much in flux at this point. Even trying to
get it into 8.4, given its late start in the development process, just
reflects wishful thinking and not the kind of hard discipline we need to
keep our release process organized. Optimism is nice and all, but with
so many people and companies relying on us, we don't have the luxury of
optimism. If people want to be optimimistic going into the development
cycle, fine, but at the end we have to be practical, because failure
will lead a disappointment with the community which will be palpable.
(Think back to the frustration we have felt about delayed releases, and
features we thought we were going to get, but didn't.)

As for the process used, I think it is useful to understand how
committers choose what to work on next. One criteria is that the patch
has stabilized; if a patch is still be modified regularly, the
committer might as well work on another patch that has stabilized. Now,
a committer could ask for the patch to stabilize to work on it, but if
he has other patches that are stable, there is no point in asking for a
stable version; he might as well work on just stable ones until only
unstable ones are left.

Now, maybe this is unfair to patches that are frequently updated, but
this is the typical process we follow, and it explains why the patches
above have not gotten near commit status yet.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +