Re: SQL command to edit postgresql.conf, with comments

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Darren Duncan <darren(at)darrenduncan(dot)net>, postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SQL command to edit postgresql.conf, with comments
Date: 2010-10-14 13:50:15
Message-ID: 17181.1287064215@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Allow me to insist on this some more, because there's something
> important going on here. The other proposal (.auto) have a major failure
> mode that I don't think is acceptable.

> SET PERMANENT work_mem TO '8 MB';
> select pg_reload_conf();

> There's simply no way after this sequence to guess the current active
> value of work_mem,

Um, other than "show work_mem" or "select from pg_settings"?

The fact is that you cannot know the active value anyway without
checking, because what you did with SET PERMANENT might be overridden
in various session-local ways. The proposal for hand-edited versus
machine-edited files just adds one more layer of possible overrides
to the existing half-dozen layers, all of which are widely considered
features not bugs. So I see no merit in your argument.

> I'm being told that we're talking about something over 200 files and
> that's too many.

Yup, you're dead right about that. Backup/restore of configurations
would become a real mess.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Geery 2010-10-14 14:02:12 Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch
Previous Message Kenneth Marshall 2010-10-14 13:46:16 Re: Why do we have a database specification in .pgpass?