Re: 9.2RC1 wraps this Thursday ...

On Tue, Aug 21, 2012 at 10:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> ... or at least, that's what the schedule says. I don't think we can
> honestly produce a "release candidate" when there are still open issues
> listed as blockers at
> http://wiki.postgresql.org/wiki/PostgreSQL_9.2_Open_Items
> We need to either get something done about those, conclude that they're
> not blockers, or postpone RC1.
>
> The items currently listed as blockers are:
>
> * GiST indexes vs fuzzy comparisons used by geometric types
> ** Alexander proposed a patch that would support the current behavior, but should we change the behavior instead?
>
> I put this in the blocker list because I was hoping to get some
> conversation going about the whole issue of fuzzy comparisons in the
> geometric stuff. However, the time for making any basic semantic
> revisions in 9.2 is long past. We could perhaps look at applying
> Alexander's more restricted patch, but maybe even that is too
> destabilizing at this point. I'm inclined to move the whole thing onto
> the "long term issues" list. Comments?

Agree.

> * Should we fix tuple limit handling, or redefine 9.x behavior as correct?
> ** The consensus seems to be to change the documentation to match the current behavior.
>
> At this point this is just a pre-existing documentation bug. Somebody
> ought to do something about it at some point, but it hardly seems like
> a release blocker.

Agree.

> * keepalives
>
> I don't know who put this item in, or what it refers to, since it has
> no supporting link. Unless somebody steps forward with an explanation
> of what the blocker issue is here, this entry is going to disappear.

I don't know who added this either, but Simon addressed it, so it can
be moved to resolved. It referred to some changes to the
walsender/walreceiver protocol that were made for 9.2 but still a bit
half-baked.

> * pg_ctl crashes on Win32 when neither PGDATA nor -D specified
>
> I'm not sure that this qualifies as a release blocker either --- isn't
> it a plain-vanilla pre-existing bug? And what does the proposed patch
> have to do with the stated problem? (Even if you define the problem
> as "make sure we're restricted" rather than the stated symptom, the
> patch looks rather fragile and Rube Goldbergian ... isn't there a way
> to actually test if we're in a restricted process?)

If this isn't a regression, it's not a release blocker.

> * Checkpointer process split broke fsync'ing
> ** bug is fixed, but now we had better recheck earlier performance claims
>
> Is anyone actually going to do any performance testing on this?

I am unlikely to have time between now and release.

> * View options are problematic for pg_dump
>
> I had hoped those who created this problem were going to fix it, but
> given the lack of response I guess I'll have to.

This is my fault, but my hackers inbox got flooded and this got lost
in the shuffle. Sorry. I can probably devote some time to it today
if you don't want to be bothered with it. Do you have a sense of what
the right fix is?

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