Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

From: Cédric Villemain <cedric(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Josh Berkus'" <josh(at)agliodbs(dot)com>, "'Robert Haas'" <robertmhaas(at)gmail(dot)com>, "'Fujii Masao'" <masao(dot)fujii(at)gmail(dot)com>
Subject: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Date: 2013-07-30 07:39:05
Message-ID: 201307300939.09836.cedric@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Le lundi 29 juillet 2013 18:03:21, Alvaro Herrera a écrit :
> > Why not harcode in ParseConfigFp() that we should parse the auto.conf
> > file at the end (and/or if USE_AUTO_CONF is not OFF) instead of
> > hacking ProcessConfigFile() with data_directory ? (data_directory should
> > be set at this point) ... just thinking, a very convenient way to
> > enable/disable that is just to add/remove the include directive in
> > postgresql.conf. So no change should be required in ParseConf at all.
> > Except maybe AbsoluteConfigLocation which should prefix the path to
> > auto.conf.d with data_directory. What I like with the include directive
> > is that Sysadmin can define some GUC *after* the auto.conf so he is sure
> > those are not 'erased' by auto.conf (or by the DBA).
>
> Why do you think DBAs would like an option to disable this feature? I
> see no point in that. And being able to relocate the parsing of
> auto.conf to be in the middle of postgresql.conf instead of at the end
> ... that seems nightmarish. I mean, things are *already* nontrivial to
> follow, I don't see what would can come from a DBA running ALTER SYSTEM
> and wondering why their changes don't take.

I don't find that hard to do nor to understand, but if that has already reach a
consensus then let's do that.

> > Also, it looks very interesting to stick to an one-file-for-many-GUC when
> > we absolutely don't care : this file should (MUST ?) not be edited by
> > hand. The thing achieve is that it limits the access to ALTER SYSTEM.
> > One file per GUC allows to LWlock only this GUC, isn't it ? (and also
> > does not require machinery for holding old/new auto GUC, or at least
> > more simple).
>
> This has already been debated, and we have already reached consensus
> (one file to rule them all). I don't think it's a good idea to go over
> all that discussion again.

ok, I've only lost track for the consensus based on the technical objective.

--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Cédric Villemain 2013-07-30 07:45:47 Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Previous Message Gibheer 2013-07-30 07:10:01 Re: Patch for reserved connections for replication users