Merging postgresql.conf and postgresql.auto.conf

Sawada Masahiko <sawada.mshk@gmail.com> writes:

The postgresql.auto.conf is loaded after loading of postgresql.conf
whenever configuration file is loaded or reloaded.
This means that parameter in postgresql.auto.conf is quite high
priority, so the parameter in postgresql.conf does not work at all
even if user set it manually.

If user want to change stopped postgresql server then user need to
merge two configuration file(postgresql.conf and postgresql.auto.conf)
while maintaining the consistency manually.

From an operational perspective having a written config with duplicate

entries is not good thing.
I think we need to merge two configuration file into one (or more than
one, if it uses like 'include' word)

The one solution is to add merging tool/commnand which merges two
configuration file while maintaining the consistency.
This topic have been already discussed?

Yes. The entire reason that postgresql.auto.conf is separate is that
we despaired of reading and rewriting postgresql.conf automatically
without making a hash of material in the comments. Calling the logic
a "merge tool" does not make that problem go away.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Jan 15, 2015 at 12:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Sawada Masahiko <sawada.mshk@gmail.com> writes:

The postgresql.auto.conf is loaded after loading of postgresql.conf
whenever configuration file is loaded or reloaded.
This means that parameter in postgresql.auto.conf is quite high
priority, so the parameter in postgresql.conf does not work at all
even if user set it manually.

If user want to change stopped postgresql server then user need to
merge two configuration file(postgresql.conf and postgresql.auto.conf)
while maintaining the consistency manually.

From an operational perspective having a written config with duplicate

entries is not good thing.
I think we need to merge two configuration file into one (or more than
one, if it uses like 'include' word)

The one solution is to add merging tool/commnand which merges two
configuration file while maintaining the consistency.
This topic have been already discussed?

Yes. The entire reason that postgresql.auto.conf is separate is that
we despaired of reading and rewriting postgresql.conf automatically
without making a hash of material in the comments. Calling the logic
a "merge tool" does not make that problem go away.

The merge tool do not only to merge the all parameters in two
configuration into one file but also to remove duplicate parameters.
That is, the configuration files will be one file in logically.

It will be clearly complicated work that the user need to rewrite
postgresql.conf manually while maintaining the consistency.
(On top of that, The executing of ALTER SYSTEM command is not allowed
user except super user.)

Is it bad that ALTER SYSTEM parses postgresql.conf again at
AlterSystemSetConfigFile() to get line number and file name of that
parameter?
(or postgresql continue to keep line number and file name of parameter)

Regards,

-------
Sawada Masahiko

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Sawada Masahiko <sawada.mshk@gmail.com> writes:

On Thu, Jan 15, 2015 at 12:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Yes. The entire reason that postgresql.auto.conf is separate is that
we despaired of reading and rewriting postgresql.conf automatically
without making a hash of material in the comments. Calling the logic
a "merge tool" does not make that problem go away.

The merge tool do not only to merge the all parameters in two
configuration into one file but also to remove duplicate parameters.
That is, the configuration files will be one file in logically.

I'll just say one more time that if we thought this could work, we'd not
have arrived at the separate-files design to begin with. You can work
on it if you like, but I will bet a good deal that you will not end up
with something that gets accepted.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Jan 15, 2015 at 1:15 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Sawada Masahiko <sawada.mshk@gmail.com> writes:

On Thu, Jan 15, 2015 at 12:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Yes. The entire reason that postgresql.auto.conf is separate is that
we despaired of reading and rewriting postgresql.conf automatically
without making a hash of material in the comments. Calling the logic
a "merge tool" does not make that problem go away.

The merge tool do not only to merge the all parameters in two
configuration into one file but also to remove duplicate parameters.
That is, the configuration files will be one file in logically.

I'll just say one more time that if we thought this could work, we'd not
have arrived at the separate-files design to begin with. You can work
on it if you like, but I will bet a good deal that you will not end up
with something that gets accepted.

Yep, I don't intend to propose again that.
Because I thought that the maintaining of configuration file will be
complicated,
so I just thought we can add supporting tool.

Regards,

-------
Sawada Masahiko

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

----- Original Message -----

From: Sawada Masahiko <sawada.mshk@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Sent: Wednesday, 14 January 2015, 16:09
Subject: Re: [HACKERS] Merging postgresql.conf and postgresql.auto.conf

On Thu, Jan 15, 2015 at 12:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Sawada Masahiko <sawada.mshk@gmail.com> writes:

The postgresql.auto.conf is loaded after loading of postgresql.conf
whenever configuration file is loaded or reloaded.
This means that parameter in postgresql.auto.conf is quite high
priority, so the parameter in postgresql.conf does not work at all
even if user set it manually.

If user want to change stopped postgresql server then user need to
merge two configuration file(postgresql.conf and postgresql.auto.conf)
while maintaining the consistency manually.

From an operational perspective having a written config with

duplicate

entries is not good thing.
I think we need to merge two configuration file into one (or more than
one, if it uses like 'include' word)

The one solution is to add merging tool/commnand which merges two
configuration file while maintaining the consistency.
This topic have been already discussed?

Yes. The entire reason that postgresql.auto.conf is separate is that
we despaired of reading and rewriting postgresql.conf automatically
without making a hash of material in the comments. Calling the logic
a "merge tool" does not make that problem go away.

The merge tool do not only to merge the all parameters in two
configuration into one file but also to remove duplicate parameters.
That is, the configuration files will be one file in logically.

I think the point is that you can't really interpret the context of comments with an automated tool, so you'd probably construct a misleading conf file. I created something to mash conf files together in perl, but mash them together is all it does: https://github.com/glynastill/pg_upgrade_conf

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Jan 14, 2015 at 9:01 PM, Sawada Masahiko <sawada.mshk@gmail.com>
wrote:

Hi all,

The postgresql.auto.conf is loaded after loading of postgresql.conf
whenever configuration file is loaded or reloaded.
This means that parameter in postgresql.auto.conf is quite high
priority, so the parameter in postgresql.conf does not work at all
even if user set it manually.

If user want to change stopped postgresql server then user need to
merge two configuration file(postgresql.conf and postgresql.auto.conf)
while maintaining the consistency manually.

I think one way to currently do it is with the help of Alter System .. Reset
command. Basically user can check via pg_settings, if the variable
belongs to postgresql.auto.conf and he knows already a duplicate copy
of same is available in postrgresql.conf and that is the value he want to
use, then RESET command could be used to remove the setting from
postgresql.auto.conf

From an operational perspective having a written config with duplicate
entries is not good thing.
I think we need to merge two configuration file into one (or more than
one, if it uses like 'include' word)

The one solution is to add merging tool/commnand which merges two
configuration file while maintaining the consistency.

If you want to think of some solution which can make the usage of Alter
System more convenient, then we should think only in terms of change/
remove the value in postgresql.auto.conf as that is the place where we
have added values programatically.

One thought I have in this line is that currently there doesn't seem to be
a way to know if the setting has an entry both in postgresql.conf and
postgresql.auto.conf, if we can have some way of knowing the same
(pg_settings?), then it could be convenient for user to decide if the value
in postgresql.auto.conf is useful or not and if it's not useful then use
Alter System .. Reset command to remove the same from
postgresql.auto.conf.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

On Thu, Jan 15, 2015 at 2:02 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:

On Wed, Jan 14, 2015 at 9:01 PM, Sawada Masahiko <sawada.mshk@gmail.com>
wrote:

Hi all,

The postgresql.auto.conf is loaded after loading of postgresql.conf
whenever configuration file is loaded or reloaded.
This means that parameter in postgresql.auto.conf is quite high
priority, so the parameter in postgresql.conf does not work at all
even if user set it manually.

If user want to change stopped postgresql server then user need to
merge two configuration file(postgresql.conf and postgresql.auto.conf)
while maintaining the consistency manually.

I think one way to currently do it is with the help of Alter System .. Reset
command. Basically user can check via pg_settings, if the variable
belongs to postgresql.auto.conf and he knows already a duplicate copy
of same is available in postrgresql.conf and that is the value he want to
use, then RESET command could be used to remove the setting from
postgresql.auto.conf

It sounds convenient.
e.g., It can reset one variable using by like RESET command, and reset
all variable using by RESET ALL command

From an operational perspective having a written config with duplicate
entries is not good thing.
I think we need to merge two configuration file into one (or more than
one, if it uses like 'include' word)

The one solution is to add merging tool/commnand which merges two
configuration file while maintaining the consistency.

If you want to think of some solution which can make the usage of Alter
System more convenient, then we should think only in terms of change/
remove the value in postgresql.auto.conf as that is the place where we
have added values programatically.

One thought I have in this line is that currently there doesn't seem to be
a way to know if the setting has an entry both in postgresql.conf and
postgresql.auto.conf, if we can have some way of knowing the same
(pg_settings?), then it could be convenient for user to decide if the value
in postgresql.auto.conf is useful or not and if it's not useful then use
Alter System .. Reset command to remove the same from
postgresql.auto.conf.

I think one way is that pg_settings has file name of variables, But
It would not affect to currently status of postgresql.conf
So we would need to parse postgresql.conf again at that time.

Regards,

-------
Sawada Masahiko

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, Jan 15, 2015 at 9:48 PM, Sawada Masahiko <sawada.mshk@gmail.com>
wrote:

On Thu, Jan 15, 2015 at 2:02 PM, Amit Kapila <amit.kapila16@gmail.com>

wrote:

One thought I have in this line is that currently there doesn't seem to

be

a way to know if the setting has an entry both in postgresql.conf and
postgresql.auto.conf, if we can have some way of knowing the same
(pg_settings?), then it could be convenient for user to decide if the

value

in postgresql.auto.conf is useful or not and if it's not useful then use
Alter System .. Reset command to remove the same from
postgresql.auto.conf.

I think one way is that pg_settings has file name of variables, But
It would not affect to currently status of postgresql.conf
So we would need to parse postgresql.conf again at that time.

Yeah that could be a possibility, but I think that will break the existing
command('s) as this is the common infrastructure used for SHOW ..
commands as well which displays the guc value that is used by
current session rather than the value in postgresql.conf.

I don't know how appealing it would be to others, but a new view
like pg_file_settings which would display the settings in file could
be meaningful for your need.

Another way is user can do pg_reload_conf() to see the latest
values (excluding values for server startup time parameters).

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

On Fri, Jan 16, 2015 at 12:54 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:

On Thu, Jan 15, 2015 at 9:48 PM, Sawada Masahiko <sawada.mshk@gmail.com>
wrote:

On Thu, Jan 15, 2015 at 2:02 PM, Amit Kapila <amit.kapila16@gmail.com>
wrote:

One thought I have in this line is that currently there doesn't seem to
be
a way to know if the setting has an entry both in postgresql.conf and
postgresql.auto.conf, if we can have some way of knowing the same
(pg_settings?), then it could be convenient for user to decide if the
value
in postgresql.auto.conf is useful or not and if it's not useful then use
Alter System .. Reset command to remove the same from
postgresql.auto.conf.

I think one way is that pg_settings has file name of variables, But
It would not affect to currently status of postgresql.conf
So we would need to parse postgresql.conf again at that time.

Yeah that could be a possibility, but I think that will break the existing
command('s) as this is the common infrastructure used for SHOW ..
commands as well which displays the guc value that is used by
current session rather than the value in postgresql.conf.

You're right.
pg_setting and SHOW command use value in current session rather than
config file.
It might break these common infrastructure.

I don't know how appealing it would be to others, but a new view
like pg_file_settings which would display the settings in file could
be meaningful for your need.

Another way is user can do pg_reload_conf() to see the latest
values (excluding values for server startup time parameters).

I prefer the former. Because the latter would not handle all guc
variables as you said.
The new view like pg_file_setting has guc variable and config file
which has corresponding guc variable.
It would be helpful view for like ALTER SYSTEM ... RESET and that
command might be beneficial feature for user who want to manage
configuration file manually, I would like to propose them.

Regards,

-------
Sawada Masahiko

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Jan 16, 2015 at 9:55 PM, Sawada Masahiko <sawada.mshk@gmail.com>
wrote:

On Fri, Jan 16, 2015 at 12:54 PM, Amit Kapila <amit.kapila16@gmail.com>

wrote:

I don't know how appealing it would be to others, but a new view
like pg_file_settings which would display the settings in file could
be meaningful for your need.

Another way is user can do pg_reload_conf() to see the latest
values (excluding values for server startup time parameters).

I prefer the former. Because the latter would not handle all guc
variables as you said.
The new view like pg_file_setting has guc variable and config file
which has corresponding guc variable.
It would be helpful view for like ALTER SYSTEM ... RESET and that
command might be beneficial feature for user who want to manage
configuration file manually, I would like to propose them.

Okay, but I think it would be better to start a new thread
as this proposal seems to be different than your original
idea.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Sawada Masahiko wrote

On Fri, Jan 16, 2015 at 12:54 PM, Amit Kapila &lt;

amit.kapila16@

&gt; wrote:

On Thu, Jan 15, 2015 at 9:48 PM, Sawada Masahiko &lt;

sawada.mshk@

&gt;

wrote:

On Thu, Jan 15, 2015 at 2:02 PM, Amit Kapila &lt;

amit.kapila16@

&gt;

wrote:

One thought I have in this line is that currently there doesn't seem

to

be
a way to know if the setting has an entry both in postgresql.conf and
postgresql.auto.conf, if we can have some way of knowing the same
(pg_settings?), then it could be convenient for user to decide if the
value
in postgresql.auto.conf is useful or not and if it's not useful then

use

Alter System .. Reset command to remove the same from
postgresql.auto.conf.

I think one way is that pg_settings has file name of variables, But
It would not affect to currently status of postgresql.conf
So we would need to parse postgresql.conf again at that time.

Yeah that could be a possibility, but I think that will break the
existing
command('s) as this is the common infrastructure used for SHOW ..
commands as well which displays the guc value that is used by
current session rather than the value in postgresql.conf.

You're right.
pg_setting and SHOW command use value in current session rather than
config file.
It might break these common infrastructure.

Two changes solve this problem in what seems to be a clean way.
1) Upon each parsing of postgresql.conf we store all assigned variables
somewhere
2) We display these assignments in a new pg_settings column named
"system_reset_val"

I would also extend this to include:
a) upon each parsing of postgresql.auto.conf we store all assigned variables
somewhere (maybe the same place as postgresql.conf and simply label the file
source)
b) add an "alter_system_val" field to show that value (or null)
c) add a "db_role_val" to show the current value for the session via
pg_db_role_setting
c.1) add a "db_role_id" to show the named user that is being used for the
db_role_val lookup

The thinking for c.1 is that in situations with role hierarchies and SET
ROLE usage it would be nice to be able to query what the connection role -
the one used during variable lookup - is.

I'm probably going overkill on this but there are not a lot of difference
sources nor do they change frequently so extending the pg_settings view to
be more of a one-stop-shopping for this information seems to make sense.

As it relates back to this thread the desired "merging" ends up being done
inside this view and at least gives the DBA a central location (well, along
with pg_db_role_setting) to go and look at the configuration landscape for
the system.

David J.

--
View this message in context: http://postgresql.nabble.com/Merging-postgresql-conf-and-postgresql-auto-conf-tp5833910p5834386.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston <
david.g.johnston@gmail.com> wrote:

You're right.
pg_setting and SHOW command use value in current session rather than
config file.
It might break these common infrastructure.

Two changes solve this problem in what seems to be a clean way.
1) Upon each parsing of postgresql.conf we store all assigned variables
somewhere
2) We display these assignments in a new pg_settings column named
"system_reset_val"

I would also extend this to include:
a) upon each parsing of postgresql.auto.conf we store all assigned

variables

somewhere (maybe the same place as postgresql.conf and simply label the

file

source)

Do we need to perform this parsing whenever user queries pg_settings?
I think it might lead to extra cycles of reading file when user won't even
need it and as the code is shared with SHOW commands that could be
slightly complicated.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila <amit.kapila16@gmail.com>
wrote:

On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston <
david.g.johnston@gmail.com> wrote:

You're right.
pg_setting and SHOW command use value in current session rather than
config file.
It might break these common infrastructure.

Two changes solve this problem in what seems to be a clean way.
1) Upon each parsing of postgresql.conf we store all assigned variables
somewhere
2) We display these assignments in a new pg_settings column named
"system_reset_val"

I would also extend this to include:
a) upon each parsing of postgresql.auto.conf we store all assigned

variables

somewhere (maybe the same place as postgresql.conf and simply label the

file

source)

Do we need to perform this parsing whenever user queries pg_settings?
I think it might lead to extra cycles of reading file when user won't even
need it and as the code is shared with SHOW commands that could be
slightly complicated.

There would be no parsing upon reading of pg_settings, only lookups. The
existing parsing would simply have its values saved to the catalogs that
will be involved in the underlying pg_setting view query.

David J.​

On Sat, Jan 17, 2015 at 10:41 AM, David Johnston <david.g.johnston@gmail.com>
wrote:

On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila <amit.kapila16@gmail.com>

wrote:

On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston <

david.g.johnston@gmail.com> wrote:

You're right.
pg_setting and SHOW command use value in current session rather than
config file.
It might break these common infrastructure.

Two changes solve this problem in what seems to be a clean way.
1) Upon each parsing of postgresql.conf we store all assigned variables
somewhere
2) We display these assignments in a new pg_settings column named
"system_reset_val"

I would also extend this to include:
a) upon each parsing of postgresql.auto.conf we store all assigned

variables

somewhere (maybe the same place as postgresql.conf and simply label

the file

source)

Do we need to perform this parsing whenever user queries pg_settings?
I think it might lead to extra cycles of reading file when user won't

even

need it and as the code is shared with SHOW commands that could be
slightly complicated.

There would be no parsing upon reading of pg_settings, only lookups. The

existing parsing would simply have its values saved to the catalogs that
will be involved in the underlying pg_setting view query.

So are you telling that whenever we read, save the settings
to some catalog (probably a new one)?

Will that completely address the problem specified in this thread,
as those values could probably be old (when last time server is
started or at last SIGHUP time values)?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

On Fri, Jan 16, 2015 at 10:19 PM, Amit Kapila <amit.kapila16@gmail.com>
wrote:

On Sat, Jan 17, 2015 at 10:41 AM, David Johnston <
david.g.johnston@gmail.com> wrote:

On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila <amit.kapila16@gmail.com>

wrote:

On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston <

david.g.johnston@gmail.com> wrote:

You're right.
pg_setting and SHOW command use value in current session rather than
config file.
It might break these common infrastructure.

Two changes solve this problem in what seems to be a clean way.
1) Upon each parsing of postgresql.conf we store all assigned

variables

somewhere
2) We display these assignments in a new pg_settings column named
"system_reset_val"

I would also extend this to include:
a) upon each parsing of postgresql.auto.conf we store all assigned

variables

somewhere (maybe the same place as postgresql.conf and simply label

the file

source)

Do we need to perform this parsing whenever user queries pg_settings?
I think it might lead to extra cycles of reading file when user won't

even

need it and as the code is shared with SHOW commands that could be
slightly complicated.

There would be no parsing upon reading of pg_settings, only lookups.

The existing parsing would simply have its values saved to the catalogs
that will be involved in the underlying pg_setting view query.

So are you telling that whenever we read, save the settings
to some catalog (probably a new one)?

Will that completely address the problem specified in this thread,
as those values could probably be old (when last time server is
started or at last SIGHUP time values)?

Cache invalidation is a hard problem to solve :)

​I am reasonably content with showing the user who has just updated their
postgresql.conf file and boots/SIGHUPs the server to find that said value
hasn't taken effect that their value is indeed sitting in postgresql.conf
but that other parts of the system are preempting it from being the active
value.

David J.

On Sat, Jan 17, 2015 at 2:24 PM, David Johnston
<david.g.johnston@gmail.com> wrote:

On Fri, Jan 16, 2015 at 10:19 PM, Amit Kapila <amit.kapila16@gmail.com>
wrote:

On Sat, Jan 17, 2015 at 10:41 AM, David Johnston
<david.g.johnston@gmail.com> wrote:

On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila <amit.kapila16@gmail.com>
wrote:

On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston
<david.g.johnston@gmail.com> wrote:

You're right.
pg_setting and SHOW command use value in current session rather
than
config file.
It might break these common infrastructure.

Two changes solve this problem in what seems to be a clean way.
1) Upon each parsing of postgresql.conf we store all assigned
variables
somewhere
2) We display these assignments in a new pg_settings column named
"system_reset_val"

I would also extend this to include:
a) upon each parsing of postgresql.auto.conf we store all assigned
variables
somewhere (maybe the same place as postgresql.conf and simply label
the file
source)

Do we need to perform this parsing whenever user queries pg_settings?
I think it might lead to extra cycles of reading file when user won't
even
need it and as the code is shared with SHOW commands that could be
slightly complicated.

There would be no parsing upon reading of pg_settings, only lookups.
The existing parsing would simply have its values saved to the catalogs that
will be involved in the underlying pg_setting view query.

So are you telling that whenever we read, save the settings
to some catalog (probably a new one)?

Will that completely address the problem specified in this thread,
as those values could probably be old (when last time server is
started or at last SIGHUP time values)?

Cache invalidation is a hard problem to solve :)

I am reasonably content with showing the user who has just updated their
postgresql.conf file and boots/SIGHUPs the server to find that said value
hasn't taken effect that their value is indeed sitting in postgresql.conf
but that other parts of the system are preempting it from being the active
value.

I think it is enough to parse and store them only when server is
started and received SIGHUP.
(Probably we should add new function to read(not load) config files to
updated these new values in pg_settings like pg_read_conf())

In idea David suggested, we would not able to know name of included
file in postgresql.conf, and duplicated values in postgresql.conf.
Are they unnecessary?

Regards,

-------
Sawada Masahiko

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sat, Jan 17, 2015 at 12:19 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:

So are you telling that whenever we read, save the settings
to some catalog (probably a new one)?

Which process are you imagining would do this? Certainly not the postmaster.

Independently of that, it sounds like solving the problem from the
wrong end. I think the idea of ALTER SYSTEM .. SET ought to be that
you should EITHER edit postgresql.conf for all your configuration
changes, OR you should use ALTER SYSTEM .. SET for all of your
changes. If you mix-and-match, well, that's certainly allowed and it
will work and everything, but you - as a human being - might get
confused. I am doubtful that any technological measures we take can
ever eliminate that confusion, because it doesn't result from some
defect of the system design, but rather from the fact that splitting
up your settings between multiple locations is inherently confusing,
especially if some settings are present in multiple locations with one
value overriding the others.

Imagine that you went out and bought a second wallet or purse. Then
you take half of the stuff that is in your original one and put it in
the new one. Then you order duplicates of 20% of the items and put
the copies in the wallet or purse that doesn't already contain a copy
of that item. I predict that if you do this, you will sometimes get
confused about which one contains any particular item that you're
looking for. But this is not anyone's fault except yours, and the
solution is simple: keep everything in one place.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Jan 19, 2015 at 9:35 AM, Robert Haas <robertmhaas@gmail.com> wrote:

On Sat, Jan 17, 2015 at 12:19 AM, Amit Kapila <amit.kapila16@gmail.com>

wrote:

So are you telling that whenever we read, save the settings
to some catalog (probably a new one)?

Which process are you imagining would do this? Certainly not the

postmaster.

I think whichever process reads postgresql.conf/postgresql.auto.conf have
to do this (unless we restrict that this will be done at some other time)
and
postmaster is one of them. It seems to me that it is not good idea unless
we do it at other time like populating entries for a view.

Independently of that, it sounds like solving the problem from the
wrong end. I think the idea of ALTER SYSTEM .. SET ought to be that
you should EITHER edit postgresql.conf for all your configuration
changes, OR you should use ALTER SYSTEM .. SET for all of your
changes. If you mix-and-match, well, that's certainly allowed and it
will work and everything, but you - as a human being - might get
confused.

Right, but we can't completely eliminate such a possibility (as an
example we have some default settings like max_connections,
shared_buffers, etc). I agree with you that users should use only
way of changing the settings, however for certain rare cases (default
settings or some other) we can provide a way for user to know which
of the settings are duplicate. I think if we can provide such an
information via some view with ease then it's worth to have it.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

On Tue, Jan 20, 2015 at 9:09 AM, Amit Kapila <amit.kapila16@gmail.com>
wrote:

Right, but we can't completely eliminate such a possibility (as an
example we have some default settings like max_connections,
shared_buffers, etc). I agree with you that users should use only
way

Sorry for incomplete sentence, I mean to say "only one way"

of changing the settings, however for certain rare cases (default
settings or some other) we can provide a way for user to know which
of the settings are duplicate. I think if we can provide such an
information via some view with ease then it's worth to have it.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com