Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id D5FFE2E00CC for ; Mon, 2 Jun 2008 12:07:29 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 49303-03 for ; Mon, 2 Jun 2008 12:07:16 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from aristoteles.cuci.nl (aristoteles.cuci.nl [212.125.128.18]) by developer.postgresql.org (Postfix) with ESMTP id 8F6012E00CB for ; Mon, 2 Jun 2008 12:07:16 -0300 (ADT) Received: by aristoteles.cuci.nl (Postfix, from userid 500) id 2F238545E; Mon, 2 Jun 2008 17:07:15 +0200 (CEST) Date: Mon, 2 Jun 2008 17:07:15 +0200 From: "Stephen R. van den Berg" To: pgsql-hackers@postgresql.org Subject: Re: Overhauling GUCS Message-ID: <20080602150715.GA4217@cuci.nl> References: <48409D1E.3070208@agliodbs.com> <200806010032.53337.peter_e@gmx.net> <17932.1212415926@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17932.1212415926@sss.pgh.pa.us> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/54 X-Sequence-Number: 119167 Tom Lane wrote: >Greg Smith writes: >> Joshua has been banging a drum for a while now that all this data needs to >> get pushing into the database itself. >This is, very simply, not going to happen. Shall we go over the reasons >why not, one more time? >1. Quite a few of the GUC parameters are needed *before* one can ever >read the database; in particular the ones about file locations and >shared memory sizing. Obviously. >2. Suppose you change a parameter in a way that breaks the DB (eg, >set shared_buffers to a value larger than your kernel allows) and >try to restart. Database doesn't start. If the parameter can only >be changed back within an operating database, you're hosed. That's why those parameters will always have to be read from a textfile. Which doesn't prohibit that textfile to be generated from within the database (once up and running). And yes, if someone changes the parameter through the DB, then makes the DB write out the configfile, then restarts the DB remotely, and the change didn't work out (i.e. DB doesn't start, or crashes/hangs), he is hosed and needs to log in and change the textfile with a texteditor, no way around it. >I have no objection to providing alternative ways to edit the >configuration data, but the primary source of the settings is >going to continue to be an editable text file. Any proposals for >alternatives-to-a-text-editor have to work within that reality. I think everyone is aware of that. -- Sincerely, Stephen R. van den Berg.