Re: When malloc returns zero ...
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Jan Wieck <wieck@debis.com>, PostgreSQL Development <pgsql-hackers@postgresql.org>
Date: 2000-05-01T21:17:51Z
Lists: 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