Re: Concerns about this release

mlw <markw(at)mohawksoft(dot)com> writes:

> Tom Lane wrote:
> >
> > mlw <markw(at)mohawksoft(dot)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