On Mon, May 9, 2011 at 11:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, May 8, 2011 at 1:04 AM, Tom Lane <tgl@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