-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 20 Feb 2008 09:42:02 -0500
Andrew Dunstan <andrew@dunslane.net> wrote:
> All this discussion seems to me to be going off into the clouds,
> where every objection is met with some still more elaborate scheme. I
> think we need to look at simple, incremental, and if possible
> backwards compatible changes.
The simplest solution I can think of is:
Have a table pg_configuration (pg_settings?).
Allow that table to be inserted into but not updated or deleted from.
Provide functions to manipulate the table perhaps:
select update_settings('shared_memory','64M');
That table is used as the definitive source for "building" the
postgresql.conf.
The postgresql.conf is pushed to disk each time the system is reloaded
via:
refresh_settings();
Refresh_settings would be called as an initial startup function as
well. So if you did:
pg_ctl -D data start
It would actually do:
pg_ctl -D data start; select update_settings(); pg_ctl -D data
restart;
The reason we only insert is that the function refresh_settings() calls
the max(created) for the setting. That way we can know what previous
settings for the GUC.
Other things could be added such as:
select update_settings('shared_memory','64M','Used to be 16 but we
got more ram');
The one thing this does is make the postgresql.conf basically a
placeholder. It is not definitive anymore, in the sense that settings
will be overwritten on restart. That really isn't that uncommon anyway
in other applications.
Sincerely,
Joshua D. Drake
- --
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHvN6FATb/zqfZUUQRAqlKAJ0ZHMGSfOBBUVqFGDtsNAw9b04JUgCgiRa4
T4e2P3+NqtVtiFpwPYArdBA=
=Zto3
-----END PGP SIGNATURE-----
