Re: add the source of param misconfigurations to error messages

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Jordan Deitch <jd(at)rsa(dot)pub>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: add the source of param misconfigurations to error messages
Date: 2018-11-13 23:01:46
Message-ID: 23861.1542150106@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-11-13 23:20:30 Re: date_trunc() in a specific time zone
Previous Message Andres Freund 2018-11-13 22:42:27 Re: add the source of param misconfigurations to error messages