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

Re: 9.2 release schedule

From: Noah Misch <noah(at)leadboat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>,Peter Geoghegan <peter(at)2ndquadrant(dot)com>,Bruce Momjian <bruce(at)momjian(dot)us>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 9.2 release schedule
Date: 2012-07-23 19:10:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Jul 23, 2012 at 10:29:06AM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > Seems OK, but I think we need to work a little harder on evicting some
> > things from the list of open items.  I don't think all of the things
> > listed in the blockers section really are, and I'm not sure what needs
> > to be done about some of the things that are there.
> I've got the libpq row processor thing.  That and the CHECK NO INHERIT
> syntax thing are definitely release-blockers, because we won't be able
> to change such decisions post-release (well, we could, but the pain to
> benefit ratio is bad).  I guess the SPGiST vs HS issue is a blocker too.
> A lot of the rest look like pre-existing bugs to me.

The only preexisting issues listed under "Blockers for 9.2" are "GiST indexes
vs fuzzy comparisons used by geometric types" and "Should we fix tuple limit
handling, or redefine 9.x behavior as correct?".  Also, I'm not sure what
exactly the "keepalives" item indicates.  Whether every regression deserves to
block the release is, of course, a separate question.

I think "WAL files which were restored from the archive are archived again" is
the thorniest regression, and we don't yet have a patch.

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2012-07-23 20:11:27
Subject: Re: Using pg_upgrade on log-shipping standby servers
Previous:From: Marko KreenDate: 2012-07-23 19:05:07
Subject: Re: [patch] libpq one-row-at-a-time API

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