Обсуждение: collecting open items for PG 9.1
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. 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. Thoughts? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.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
On Thu, Mar 10, 2011 at 1:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.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. OK, that sounds promising. >> 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. Well, I guess what I really trying to estimate was how much time will it take us to fix the problems we already know about. It's not impossible for replication-related items to force a catversion bump if, for example, we change the definition of pg_stat_replication, but in any event I've never been that excited about avoiding initdb between beta and release. The main issue in my book is that we're not going to actually release until we've fixed all the known regressions, and we're not going to start finding those until we push things that we THINK are relatively stable and then wait for the complaints to start rolling in. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company