Обсуждение: add the source of param misconfigurations to error messages

Hi Hackers -

The command 

$ postgres --config-file="/etc/postgresql/10/main/postgresql.conf"

can fail with the following error:

postgres: superuser_reserved_connections must be less than max_connections

even if max_connections > superuser_reserved_connections in that config file

This is due to the addition of the postgresql.auto.conf params. 
Would the community welcome a patch whereby this detail in contained in the error? 

something to the effect of:

postgres: superuser_reserved_connections must be less than max_connections (superuser_reserved_connections is set to 10
in$path$ and max_connections is set to 10 in $path$)
 

Alternatively, we can track alter system changes in the postgresql.conf, so we have a unified source of parameter
configurations.

Thanks!


-- 
Jordan Deitch
https://id.rsa.pub/

Jordan Deitch <jd@rsa.pub> writes:
> $ postgres --config-file="/etc/postgresql/10/main/postgresql.conf"
> can fail with the following error:
> postgres: superuser_reserved_connections must be less than max_connections

> This is due to the addition of the postgresql.auto.conf params.
> Would the community welcome a patch whereby this detail in contained in the error?

Seems to me it'd result in an impossibly unwieldy message, especially
once you realize you might have to deal with other value sources than
files.  Adhering to the translatability guidelines (ie, "don't construct
messages out of parts") would be problematic for that too.

We already have fairly substantial support for diagnosing such mistakes
through the pg_file_settings view, though admittedly if you don't use
that *before* restarting the server, it does not help with this.

            regards, tom lane

Hi,

On 2018-11-13 17:33:01 -0500, Tom Lane wrote:
> Jordan Deitch <jd@rsa.pub> writes:
> > $ postgres --config-file="/etc/postgresql/10/main/postgresql.conf"
> > can fail with the following error:
> > postgres: superuser_reserved_connections must be less than max_connections
> 
> > This is due to the addition of the postgresql.auto.conf params. 
> > Would the community welcome a patch whereby this detail in contained in the error? 
> 
> Seems to me it'd result in an impossibly unwieldy message, especially
> once you realize you might have to deal with other value sources than
> files.  Adhering to the translatability guidelines (ie, "don't construct
> messages out of parts") would be problematic for that too.

Note that I'm convinced this is a necessary feature.  But if we were to
do it, I'd assume we put something like this in the DETAIL not the
ERROR itself. That ought to alievate some of those concerns?


> We already have fairly substantial support for diagnosing such mistakes
> through the pg_file_settings view, though admittedly if you don't use
> that *before* restarting the server, it does not help with this.

Would be kind of useful if --describe-config, or a version thereof,
would print that kind of information too.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> On 2018-11-13 17:33:01 -0500, Tom Lane wrote:
>> Seems to me it'd result in an impossibly unwieldy message, especially
>> once you realize you might have to deal with other value sources than
>> files.  Adhering to the translatability guidelines (ie, "don't construct
>> messages out of parts") would be problematic for that too.

> Note that I'm convinced this is a necessary feature.  But if we were to
> do it, I'd assume we put something like this in the DETAIL not the
> ERROR itself. That ought to alievate some of those concerns?

It would still be pretty unwieldy.

>> We already have fairly substantial support for diagnosing such mistakes
>> through the pg_file_settings view, though admittedly if you don't use
>> that *before* restarting the server, it does not help with this.

> Would be kind of useful if --describe-config, or a version thereof,
> would print that kind of information too.

Hmm, that's an idea.  We could probably refactor the pg_file_settings
infrastructure so it could be invoked by a command line option (maybe call
it --debug-config?) and just dump the results to stdout.  That would have
the advantage that it could report on more than one error, if there is
one.

            regards, tom lane