On Wed, Jul 9, 2014 at 10:14 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Amit Kapila <amit.kapil...@gmail.com> writes: > > On Wed, Jul 9, 2014 at 6:40 AM, Mark Kirkwood < mark.kirkw...@catalyst.net.nz> > > wrote: > >> Yes, but even well behaved users will see this type of error, because > >> initdb uncomments certain values (ones that are dead certs for being > >> changed via ALTER SYSTEM subsequently like shared_buffers), and then - > >> bang! your next reload gets that "your postgresql.conf contains errors" > >> message. > > > That is the reason, why I have suggested up-thread that uncommented > > values should go to postgresql.auto.conf, that will avoid any such > > observations for a well-behaved user. > > Uh, what? That sounds like you are proposing that postgresql.conf itself > is a dead letter. Which is not going to fly. We had that conversation > already.
It might sound like that but honestly my intention was to just ease the use for users who just want to rely on Alter System. > The right way to fix this is just to avoid processing entries that get > overridden later in the configuration file scan. That won't cause anyone > to get upset about how their old habits no longer work. Okay. As mentioned upthread, I have fixed by ensuring that for duplicate config params, retain only which comes later during parsing. I think it might have been bit simpler to fix, if we try to fix after parsing is complete, but I think for that we might need to replicate the logic at multiple places. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
avoid_processing_dup_config_params_v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
