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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Selena Deckelmann <selena(at)endpoint(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: postgresql.conf: patch to have ParseConfigFile report all parsing errors, then bail
Date: 2009-03-27 14:07:31
Message-ID: 8118.1238162851@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-03-27 14:25:43 Re: New trigger option of pg_standby
Previous Message Peter Eisentraut 2009-03-27 13:47:25 Re: SSL over Unix-domain sockets