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
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 |