Re: Concerns about this release
От | Don Baccus |
---|---|
Тема | Re: Concerns about this release |
Дата | |
Msg-id | 3C1F7416.3000603@pacifier.com обсуждение исходный текст |
Ответ на | Concerns about this release (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: