On 2014-01-22 12:10:30 -0500, Tom Lane wrote: > Kevin Grittner <kgri...@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.
Wouldn't bother me overly much. But it doesn't seem too hard to avoid it. Simply split the current ProcessConfigFile() into one more phase. Currently we seem to be parsing the config file, then iterate over the list returned from that to set options. If we'd instead have one pass over the items storing the new value in a new config_generic variable, after checking, and then a second pass over all gucs setting those that have changed we should end up at the same complexity since it could be merged with the reset pass. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
