On Mon, 2004-03-22 at 10:51, Tom Lane wrote: > > 2.Use a config file. This would require some additional coding to add > > the required parsing, but is possible. > > Personally I like #2. The claim that this requires extra code seems > bogus to me --- when you are working at the C code level, reading a > table takes code too. I think both 1 and 3 represent clutter. Also, > they will introduce entirely new sets of problems that we already know > how to deal with in the case of config files, but have no experience > with for config tables. Some examples: how do you get the daemon to > notice that you changed the config (SIGHUP for config files, ?? > otherwise)? Can you easily get at the config data from a daemon process > regardless of which database it's attached to (if any)? If the config > data is in a table, what sorts of interesting problems will arise from > trying to vacuum that table itself?
I guess what I mean by extra code is extra work since I am comfortable storing data in tables, and would need to do some work to put it in a config file. Some of this conversations should change if we really are going to integrate autovacuum into the backend. My suggestions for storing config data was really assuming that we would continue to be a client app for at least one more release cycle, but I think I'm hearing that people want it in the backend now. Assuming that we are being integrated into the backend, and assuming that a autovacuum process is fired off periodically by the postmaster, I think some config items should become GUC options and others will become part of the system tables. For example: enable_autovacuum should be a GUC option, but the vacuum threshold for a given table should probably just be a new column in the pg_class table. Any data stored in the system tables will be check every time the autovacuum process is run so there won't be any problems with noticing that the admin change the threshold for a given table. > Basically I see config tables as cutting against the grain of everything > we've done to date in Postgres DBA-level configuration, and I do not see > a reason to justify that sort of reinvention. I agree if we are talking about a client app, but I think the scheme laid out above is consistent for something that is part of the backend, do you disagree? Thanks, Matthew O'Connor ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org