Re: When malloc returns zero ...
От | Tom Lane |
---|---|
Тема | Re: When malloc returns zero ... |
Дата | |
Msg-id | 1627.957215871@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: When malloc returns zero ... (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
RE: When malloc returns zero ...
Re: When malloc returns zero ... |
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > A while ago I went on record saying that elog is a pain for the user. Now > I'd like to add it's a pain for developers, too. Having what's essentially > an exception model without a way to catch exceptions is disastrous. I think that's a bit overstated ... we've gotten along fine with this model so far, and I haven't seen any compelling reason to change it. The problem at hand is not the error handling model, it's that the postmaster environment doesn't implement the model. > It's furthermore equally impossible to communicate an error message to > the server log and not have it sent to the front-end. Er, what's wrong with elog(DEBUG)? >> Offhand I think that Peter need not tackle this issue in order to do >> parsing of postmaster startup-time options, but if he wants to have >> the postmaster reread the config file at SIGHUP then it needs to be >> addressed. > The postmaster passes on the SIGHUP to all the backends but it doesn't do > anything about it itself. This was already in place, I didn't see a need > to change it. Doesn't the postmaster need to reread the config file itself in order to be sure to pass the new values to subsequently-started backends? Or is your plan that newly started backends will always parse the config file for themselves? In that case I'm not clear on why you care about the postmaster environment at all. regards, tom lane
В списке pgsql-hackers по дате отправления: