postgresql.conf: patch to have ParseConfigFile report all parsing errors, then bail

ParseConfigFile currently exits on the first parsing error. Changed
guc_file.l to report all parsing errors before exiting:
* Moved parse_error: block inside while() loop
* Removed cleanup_exit: and associated 'goto'
* Added ereport if ParseConfigFile() returns false
* changed OK to ok ;)
* Added comment - TODO: Report bogus variables in addition to parsing
errors before bailing out

-selena

--
Selena Deckelmann
End Point Corporation
selena(at)endpoint(dot)com
503-282-2512

Selena Deckelmann wrote:

> ! parse_error:
> ! if (token == GUC_EOL || token == 0)
> ! ereport(elevel,
> ! (errcode(ERRCODE_SYNTAX_ERROR),
> ! errmsg("syntax error in file \"%s\" line %u, near end of line",
> ! config_file, ConfigFileLineno - 1)));

Not that this has anything to do with the patch at hand, but I remember
thinking about this sort of error message in the past. Would it be
appropriate to move the file name and line number to an errcontext()
field?

I know somebody is going to say "but errcontext is not shown when
verbosity is set to terse", to which I say that we should fix that too.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Not that this has anything to do with the patch at hand, but I remember
> thinking about this sort of error message in the past. Would it be
> appropriate to move the file name and line number to an errcontext()
> field?

I think the message is fine as is. If you moved that information then
you'd have nothing left in the base message but "syntax error", which
is useless.

> I know somebody is going to say "but errcontext is not shown when
> verbosity is set to terse", to which I say that we should fix that too.

No, because the whole point of terse is to be terse. Adding context
to the output would just create a demand for "super terse" mode.

regards, tom lane

On Sun, 2009-03-08 at 16:27 -0700, Selena Deckelmann wrote:
> ParseConfigFile currently exits on the first parsing error. Changed
> guc_file.l to report all parsing errors before exiting:
> * Moved parse_error: block inside while() loop
> * Removed cleanup_exit: and associated 'goto'
> * Added ereport if ParseConfigFile() returns false
> * changed OK to ok ;)
> * Added comment - TODO: Report bogus variables in addition to parsing
> errors before bailing out

These are very good changes, good news.

Is it possible to check for parameters that have been changed, yet will
not be applied at reload? It's a common error to change something like
shared_buffers and then expect that to have changed when you reload. It
would be useful to issue messages when that has occurred.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

Hi!

Simon Riggs wrote:
> On Sun, 2009-03-08 at 16:27 -0700, Selena Deckelmann wrote:
>> ParseConfigFile currently exits on the first parsing error. Changed
>> guc_file.l to report all parsing errors before exiting:
>> * Moved parse_error: block inside while() loop
>> * Removed cleanup_exit: and associated 'goto'
>> * Added ereport if ParseConfigFile() returns false
>> * changed OK to ok ;)
>> * Added comment - TODO: Report bogus variables in addition to parsing
>> errors before bailing out
>
> These are very good changes, good news.

Thanks :)

> Is it possible to check for parameters that have been changed, yet will
> not be applied at reload?

This was already implemented! :) For example:

LOG: attempted change of parameter "shared_buffers" ignored
DETAIL: This parameter cannot be changed after server start.
LOG: attempted change of parameter "max_prepared_transactions" ignored
DETAIL: This parameter cannot be changed after server start.

A thing that could be added, however, is reporting of all invalid (as
opposed to valid, but requires a restart to apply) parameters before
exiting. This change requires refactoring ProcessConfigFile() more
significantly, as the parsing and validity checks are done separately,
and are exited with gotos. :)

I haven't tried to change this yet, but was planning to.

-selena

--
Selena Deckelmann
End Point Corporation

On Tue, 2009-03-10 at 07:30 -0700, Selena Deckelmann wrote:

> > Is it possible to check for parameters that have been changed, yet will
> > not be applied at reload?
>
> This was already implemented! :) For example:
>
> LOG: attempted change of parameter "shared_buffers" ignored
> DETAIL: This parameter cannot be changed after server start.
> LOG: attempted change of parameter "max_prepared_transactions" ignored
> DETAIL: This parameter cannot be changed after server start.

OK, had that at the back of my mind for a while I guess.

> A thing that could be added, however, is reporting of all invalid (as
> opposed to valid, but requires a restart to apply) parameters before
> exiting. This change requires refactoring ProcessConfigFile() more
> significantly, as the parsing and validity checks are done separately,
> and are exited with gotos. :)
>
> I haven't tried to change this yet, but was planning to.

Can't we just do a reload, but with doit = false?

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

Simon Riggs wrote:
> On Tue, 2009-03-10 at 07:30 -0700, Selena Deckelmann wrote:

>> A thing that could be added, however, is reporting of all invalid (as
>> opposed to valid, but requires a restart to apply) parameters before
>> exiting. This change requires refactoring ProcessConfigFile() more
>> significantly, as the parsing and validity checks are done separately,
>> and are exited with gotos. :)
>>
>> I haven't tried to change this yet, but was planning to.
>
> Can't we just do a reload, but with doit = false?

That would also be cool. Like an 'apachectl configtest'.

There are five places where a 'goto' is used in guc-file.l needs to be
changed to make this work (in addition to adding an option to pg_ctl).

It should be pretty straightforward, and I'll have a look at it tonight.

-selena

--
Selena Deckelmann
End Point Corporation

Selena Deckelmann <selena(at)endpoint(dot)com> writes:
> ParseConfigFile currently exits on the first parsing error. Changed
> guc_file.l to report all parsing errors before exiting:

This seems like basically a good idea, but consider what happens if
you make a really major-league screwup in your postgresql.conf
(say, you accidentally copy the text of "War and Peace" into it).
You'll get megabytes of mostly-useless bleating in your log file.
Multiply that by the number of active backends, if you're unlucky
enough to have done it at log level DEBUG2. And not only are you
bloating your log, but it's going to take a fair amount of time
for all the backends to read and complain (or not) about the whole
file.

So I think a couple of safety valves would be prudent:

1. If IsUnderPostmaster, fall out after the first error, same as now.

2. Even in the postmaster, count the number of errors reported,
and give up after say 100. By that point it's much more likely
that you're reading War and Peace than that you're continuing to
contribute to the enlightenment of the DBA.

regards, tom lane