Re: collecting open items for PG 9.1

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Now that alpha4 is out the door (and the bug reports have begun to
> roll in), we should probably give some more serious thought to the
> road from here to beta1. There's a partial list of open items here:
> http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Open_Items

> Many of those items related to synchronous replication, but I think
> that's because Fujii Masao just made a big update rather than due to
> any lack of open items elsewhere - in particular, it seems like there
> may be some open items related to collation support, and perhaps other
> things. I think it would be helpful if anyone who is aware of other
> things that ought to be addressed before we go to beta could add them
> there - that way, we have a clear list that everyone can see of what
> we need to hammer through, and we can start hammering it.

Yeah, I currently have a list of about two dozen things I don't like
about collations, though some of those may reduce to "this needs to be
commented better" once I understand the code more fully. That list is in
no shape to be put on the wiki though; it's mostly not intelligible to
anybody but me, and it's changing too fast anyway. I'm currently hoping
to be done with that topic in a week or so.

> I am also curious what people think would be a realistic date to shoot
> for in terms of beta1. My first thought would be about a month from
> now, i.e. the second full week in April, but I have no idea whether
> that matches anyone else's thoughts on the matter. I think if it's
> going to take any longer than that, though, we probably ought to put
> out another alpha around the end of March.

Historically we've declared it beta once we think we are done with
initdb-forcing problems. There are certainly some catversion bumps that
are going to come out of the collation stuff, because of changes in
expression node contents affecting stored rules. But the other areas
that seem likely to be pretty buggy, like SSI and sync rep, operate
mostly below the level of anything that might require a catversion bump.
In any case, the existence of pg_upgrade means that "might we need
another initdb?" is not as strong a consideration as it once was, so
I'm not sure if we should still use that as a criterion. I don't know
quite what "ready for beta" should mean otherwise, though.

regards, tom lane