On Mon, May 9, 2011 at 11:10 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sun, May 8, 2011 at 1:04 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Yes, definitely. Perhaps summarize as "rethink how we handle partially >>> correct postgresql.conf files". Or maybe Robert sees it as "rethink >>> approach to making sure all backends share the same value of critical >>> settings"? Or maybe those are two different TODOs? > >> The second is what I had in mind. I'm thinking that at least for >> critical GUCs we need a different mechanism for making sure everything >> stays in sync, like having the postmaster write a precompiled file and >> convincing the backends to read it in some carefully synchronized >> fashion. However, it's not clear to me whether something along those >> lines (or some other lines) would solve the problem you were >> complaining about; therefore it's possible, as you say, that there are >> two separate action items here. Or maybe not: maybe someone can come >> up with an approach that swats both problems in one go. > > Well, the thing that was annoying me was that because a backend saw one > value in postgresql.conf as incorrect, it was refusing to apply any > changes at all from postgresql.conf. And worse, there was no log entry > to give any hint what was going on. This doesn't seem to me to have > much to do with the problem you're on about. I agree it's conceivable > that someone might think of a way to solve both issues at once, but > I think we'd better list them as separate TODOs.
OK by me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers