Re: Recovery Test Framework

From: "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com>
To: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Recovery Test Framework
Date: 2009-01-12 16:07:08
Message-ID: 1d4e0c10901120807t71ae9d2ia686882d30cd509d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 12, 2009 at 4:56 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> I disagree at least with hot standby. I've been using/testing (as
> have others) it under a variety of workloads for several months now
> with no issues outside of corrected issues in the very early patches.
> Also, a relatively few amount of people update/build from cvs
> frequently so being committed late in the release cycle isn't as
> important as you are claiming...the real 'wider net' testing happens
> when the beta period begins.

Update/build from CVS != Update/build from CVS + apply the replication
patches + test them explicitely.

That said, I didn't have the time to test them myself so I feel also
responsible for that.

My point is that what Simon currently has (and so what you tested) is
different from what is going to be commited (note the "final" in what
I wrote) and I suspect there will be a certain number of non
negligible adjustments (see the last discussions between Simon and
Heikki and I don't think Tom has taken a look at these patches yet).

I'm not sure that the beta/rc testing cycle is sufficient for such a
critical feature and that we probably need some time to polish it.

But once again, it's just MVHO.

--
Guillaume

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2009-01-12 16:09:36 pg_restore -1 vs -C and -c
Previous Message Tom Lane 2009-01-12 16:00:41 pgsql: Tweak order of operations in BitmapHeapNext() to avoid the case