Re: Concerns about this release
От | Jason Earl |
---|---|
Тема | Re: Concerns about this release |
Дата | |
Msg-id | 87ofkwe4xb.fsf@npa01zz001.simplot.com обсуждение исходный текст |
Ответ на | Re: Concerns about this release (mlw <markw@mohawksoft.com>) |
Список | pgsql-hackers |
mlw <markw@mohawksoft.com> writes: > Tom Lane wrote: > > > > mlw <markw@mohawksoft.com> writes: > > > I kind of second your opinion here. I also have my doubts that the > > > default is not as well tested as the option. > > > > By that logic, we could never make any new releases, or at least never > > add any new code. "New code isn't as well tested as old code" is an > > unhelpful observation. > > Oh come on now. That isn't the point. One could, however, leave the > default "as is" and make the new feature the option for at least one > release cycle. That seem pretty sane without being overly > conservative. Actually I think that it makes a lot of sense to change the semantics of VACUUM. None of us here like the way that vacuum currently works. The PostgreSQL hackers could have given the new VACUUM a different name, but a million email messages in the mailing list archives tell newbies to VACUUM. That's why changing VACUUM so that it "does what you mean" makes perfect sense. I am looking forward to being able to vacuum my database while the plant is still running. For most people (especially the new PostgreSQL users) the new VACUUM is precisely what they want. They don't want to lock their tables while vacuuming. The fact that Tom trusts the new vacuum over the old one should clinch the matter. Those of you that have 7.1 databases in production that don't mind the current VACUUM implementation can simply wait until the new VACUUM gets put out in production and see how it goes. If you are happy with what you have now their is little pressure to upgrade. However, changing the default makes it easier for new PostgreSQL users. It also means that the PostgreSQL hackers can say that their database is ready for 24x7 operation in "the default" mode. Advertising is important too. > > FWIW, I trust lazy VACUUM a lot *more* than I trust the old VACUUM > > code. Read the tuple-chain-moving logic in vacuum.c sometime, and > > then tell me how confident you feel in it. (My gut tells me that > > that logic is responsible for the recent reports of duplicate > > tuples in 7.1.*, though I can't yet back this up with any > > evidence.) > > > > > Plus, aren't there some isses with the non-locking vacuum? > > > > Such as? > > I'm not sure, I have vague recollection of some things (I thought the > duplicate primary keys was on 7.2), but if you think it is good, then > I'll take your word for it. > > > > > > Are all the PostgreSQL developers really, really, sure that all the new > > > features in 7.2 are ready for prime time? > > > > See above. If you like, we'll push out the release date a few years. > > Of course, the code won't get any more ready for prime time just by > > sitting on it. > > > No, that isn't my point. My point is the changes in OIDs and the new > vacuum code seem like a more drastic set of changes than previous > releases. I think that you are forgetting some of PostgreSQL's past changes. Take a look at the changelog and you will realize that removing OIDs and changine the semantics of VACUUM are peanuts compared to 7.1's transaction log, TOAST, Outer Joins, the new function manager, etc. The developers have been warning against using OIDs forever, and you can still leave them on if you need them. And the new vacuum is a vast improvement for those of us that use our databases 24x7. I see this as a bug fix of the old procedure with the option of using the old implementation if you really need it. > Again, there is a time on every project when it is speak now or > forever hold your peace. Bruce spoke, he raised some concerns, I had > similar ones. There can be no harm in doing a little retrospect. That's certainly true. I suppose the primary difference between my attitude and the yours and Bruce's is that I can't hardly wait for the new features in 7.2 :). Likewise you don't remember the massive changes in 7.1 because you *needed* them. Now you are happy with 7.1 and don't want to make radical changes :). > > I think that we've very nearly reached the point where further time in > > beta phase isn't going to yield any new info. Only putting it out as > > an official release will draw enough new users to expose remaining bugs. > > We've been through this same dynamic with every previous release; 7.2 > > won't be any different. > > I agree. Bring it on! I have good backups :). Jason
В списке pgsql-hackers по дате отправления: