Re: Remaining beta blockers
От | Robert Haas |
---|---|
Тема | Re: Remaining beta blockers |
Дата | |
Msg-id | CA+TgmoZ6M4_fxb0MYw9ScuRXrwbQvEWK+NLjZLutc=tYDPo5-w@mail.gmail.com обсуждение исходный текст |
Ответ на | Remaining beta blockers (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Remaining beta blockers
Re: Remaining beta blockers |
Список | pgsql-hackers |
On Sat, Apr 27, 2013 at 10:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > The schedule says we're going to wrap 9.3beta1 on Monday, but it doesn't > feel to me like we are anywhere near ready to ship a credible beta. > Of the items on the 9.3 open-items page, > https://wiki.postgresql.org/wiki/PostgreSQL_9.3_Open_Items > there are at least three that seem like absolute drop-dead stop-ship issues: I completely agree. I think it's considerably premature to wrap a beta at this point. We haven't resolved the issue of what to do about accidental restores into pg_catalog either; nobody replied to my last email on that thread. > 1. The matviews mess. Changing that will force initdb, more than > likely, so we need it resolved before beta1. I would like to rip out the whole notion of whether a materialized view is scannable and am happy to do that on Monday if you're willing to sit still for it. I think that's better than failing to support unlogged relations, and I'm confident that the decision to put the scannability flag in pg_class rather than the backing file is dead wrong. At the same time, I *also* agree that using the file size as a flag is untenable. > 2. The checksum algorithm business. Again, we don't get to tinker with > that anymore once we're in beta. I think it's pretty darn clear that we should change the algorithm, and I think we've got a patch to do that. So we should be able to resolve this relatively quickly. But +1 for adding a checksum algorithm ID to pg_control anyway. > 3. The ProcessUtility restructuring problem. Surely we're not going to > ship a beta with persistent buildfarm failures, which even show up > sometimes on non-CLOBBER_CACHE_ALWAYS animals, eg today at > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=nightjar&dt=2013-04-27%2009%3A27%3A00 > > As for #3, there's a draft patch, who's going to take responsibility > for that? I have been assuming that Alvaro was responsible for fixing this since he (AIUI) was the one who committed what broke it. If that's not the case, I should probably jump in, since I committed some earlier event trigger patches. Or Dimitri, as the original author of said patches. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: