Skip site navigation (1) Skip section navigation (2)

Re: do we need to postpone beta4?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: do we need to postpone beta4?
Date: 2010-07-28 22:58:38
Message-ID: AANLkTinukUrWx3CY7m78yXGipf+3Rgm05BzRJieqdLUj@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Jul 27, 2010 at 4:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Well, that's pretty much saying we won't release before September.
>
> Yup, that's what I think.  In fact I think September might be
> optimistic.  This is what happens when you fork early and allow
> developers to start focusing on new development instead of testing
> the release branch.

Actually, rewind.  I see that you moved the user-mappings issue I was
concerned about to "resolved after beta3"; I missed the fact that
you'd committed a fix there.  You also fixed the EPQ issue, and the
heap_update_redo problem evaporated.  So now we have the following
issues remaining:

* page corruption after moving tablespace
* ExplainOnePlan handles snapshots differently than ProcessQuery
* name and comment of XLogSetAsyncCommitLSN() should be changed
* Documentation fails to build as PDF

...and I wouldn't necessarily regard any of those as forcing another
beta; the first two are ancient, the third is cosmetic, and the last
one is a build system issue rather than a code change.

Obviously, it's too early to decide anything: we may yet discover more
issues that need to be addressed.  But I think we're in much better
shape than it seemed 24 hours ago.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Responses

pgsql-hackers by date

Next:From: Jeff DavisDate: 2010-07-28 23:09:18
Subject: Re: string_to_array has to be stable?
Previous:From: Greg SmithDate: 2010-07-28 22:48:58
Subject: Re: Patch to show individual statement latencies in pgbench output

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group