Re: Concerns about this release

Jason Earl wrote:


> 
> 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.


None of us?  You forgot to ask me when you polled all of us ...

I think the new VACUUM strategy has great promise, but until I see it 
running in production environments for a while that's as far as I'm 
willing to go.  I've lived with the old VACUUM for the two or so years 
I've been running PG-based websites, I can live with it a few more 
months until you run into all the table-corrupting bugs for me.  Or have 
such a successful experience that I become convinced there aren't any 
(my hope, of course!)

> It also means that the PostgreSQL hackers can say that their database is
> ready for 24x7 operation in "the default" mode.


Plenty of people already run it 24x7.


> 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.


While true, it is also true that:

1. TOAST didn't change the semantics of queries on existing tables.  It   just allows you to define tables that weren't
definablebefore.
 

2. outer joins didn't change the semantics of existing queries.  You can   write queries you couldn't write before, but
yourold queries work   without change.
 

3. The new function manager is transparent to all but those who write C   functions, other than fixing the NULL
parameterbug.
 

4. WAL was a scary change due to the scope, but it didn't change the   semantics of transactions.

5. The semantics of VACUUM have changed.  Silently (in the sense that   there's no notification or warning spewed
out).

> 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.


Or if the new one hoses your tables.   Tom's bright, but he's not 
certified bug-free.

>>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 the new VACUUM is a great thing, and frankly I don't care all 
that much about the VACUUM FULL command issue.  I tend to take the view 
that command semantics shouldn't be changed if one can avoid it.  It's a 
view built on the fact that about twenty years of my past life were 
spent as a language implementor and dealing with customer feedback when 
I've been foolish enough to make semantics changes of this sort.

I certainly wouldn't've raised this issue, at this late date, on my own.

But since Bruce did and since I'm temporarily subscribed to the list I 
feel justified in piling on :)


> Bring it on!  I have good backups :).


Uh ... if you're truly 24x7 critical then rolling back to your last 
backup wouldn't cut it, I'd think  ...



-- 
Don Baccus
Portland, OR
http://donb.photo.net, http://birdnotes.net, http://openacs.org