Re: Concerns about this release

Bruce Momjian wrote:
> 
> I know I have expressed these concerns before but lost the argument, or
> at least no one rallied to my position, but I feel I have to mention
> these again because they came up during beta.
> 
> 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 kind of second your opinion here. I also have my doubts that the
default is not as well tested as the option. Plus, aren't there some
isses with the non-locking vacuum?

> 
> 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.  These new columns are used only for non-oid
> tables, making access cumbersome, rather than the simpler oid lookup.  I
> don't even know if the current setup will allow other tables without
> oids to be referenced cleanly.  Object dependency tracking, using
> pg_depend, will also require these additional fields to track
> dependency, rather than just using the oid, and such access will be more
> confusing.
> 
> I realize the motivation for these changes were to make PostgreSQL more
> enterprise-ready, but I am concerned these changes may need to be
> modified in future releases, causing confusion and porting problems for
> users.

I don't understand why the oids were taken from the system tables.
Surely there can't be so many that it is a real problem of use. The
dangerous issue is, of course, oid reuse in system tables.

The ability to remove OIDs from user tables is a big bonus. There are so
many times when you just want to store huge amount of lookup data in a
static table, there is no need for the overhead of an OID. This saves
disk space and OID depletion (wrap around).

Are all the PostgreSQL developers really, really, sure that all the new
features in 7.2 are ready for prime time?