Re: Concerns about this release

Bruce Momjian wrote:


> My first concern is that VACUUM now defaults to the non-locking version.
> While I appreciate the new non-locking code, I imagine a release where
> non-locking VACUUM will happen automatically, making no need to run
> VACUUM.  However, locking VACUUM will still need to be run by
> administrators, so we may be left with a VACUUM no one needs to run but
> a VACUUM FULL that does need to be run, leaving us with a useless
> default for VACUUM without the FULL keyword.  Also, because VACUUM does
> not store the freetuple list between postmaster restarts, nor does it
> have any way of recording _all_ free tuples, it has to be run with a
> different frequency than the old VACUUM that I assume most people ran at
> night.  I would have preferred to leave VACUUM as locking VACUUM and
> create a new lighter option to the VACUUM command, and if light vacuum
> later becomes automatic, the option can just go away.


I've kept my mouth shut about this mostly because I've been extremely 
busy and because I've suspected my opinion is a minority one.

In general I think changing the behavior of familiar commands should be 
avoided as much as possible.  VACUUM has worked the same way "since the 
beginning" and this seems like a gratuitous semantic change.

(NOT the new code, but rather the fact that VACUUM now uses the new 
code, and the fact that you need to do a VACUUM FULL to get the old).

It just seems unnecessary.


> Second, I am concerned about the removal of oids from system tables.  I
> realize this was done to prevent oid usage, particularly by the creation
> of temp tables, but such savings only make sense when oids are turned
> off in postgresql.conf.  I imagine future releases where we have a
> separate oid counter for system/user tables, or 8-bytes oids, in which
> case the removal of oids from system tables may be needless.  We have
> seen OpenACS is broken now because the new pg_description requires a
> separate classoid/objsubid columns to uniquely access tables without
> oids, like pg_attribute


This one doesn't bother me particularly.  We were only caught by 
surprise because those of us who follow PG developments haven't been 
paying as close attention as we have in the past.  Mostly because in the 
past we've been desperate for new features and thus working with "the 
next PG beta" version, thus tracking progress and changes in upcoming 
releases has been central to managing our project.  It's a tribute to 
all the hard work you guys have done in the past couple of years that 
we've decided to support PG 7.1 as well as PG 7.2 (for those to chicken 
to change over).

In this case I just wrote a small PL/pgSQL function that queries 
"version()" and generates a view which works properly for the given 
7.1/7.2 version.

I think that's reasonable when you're mucking around system tables.  The 
new function to grab the comment is cleaner, too.

I'm not trying to undercut Bruce's overall argument, just pointing out 
that as the OpenACS 4 project manager I have no strong feelings either 
way.  Bruce, obviously, does and has thought about it a lot more than I 
have.


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