Re: Incorrectly reporting config errors - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Incorrectly reporting config errors
Date
Msg-id 13048.1390410630@sss.pgh.pa.us
Whole thread Raw
In response to Re: Incorrectly reporting config errors  (Kevin Grittner <kgrittn@ymail.com>)
Responses Re: Incorrectly reporting config errors
Re: Incorrectly reporting config errors
List pgsql-hackers
Kevin Grittner <kgrittn@ymail.com> writes:
> My preference would be to not generate noise for interim states;
> just report net changes.

Yeah.  Is it worth explicitly detecting and dropping redundant assignments
to the same variable?  A naive check for that would be O(N^2) in the
number of entries in the conf file, but perhaps that's still cheap enough
in practice.  This would mean for example that
  shared_buffers = 'oops'  shared_buffers = '128MB'

would not draw an error, which doesn't bother me but might bother
somebody.

> And don't say that a file "contains
> errors" when we mean "those options are ignored on reload; they
> will only take effect on restart".

I'm not happy about complicating that logic even more.  I think the
reasonable choices here are to reword that message somehow, or just
drop it completely.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: WAL replay should fdatasync() segments?
Next
From: Tom Lane
Date:
Subject: Re: dynamic shared memory and locks