Re: When malloc returns zero ... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: When malloc returns zero ...
Date
Msg-id 1627.957215871@sss.pgh.pa.us
Whole thread Raw
In response to Re: When malloc returns zero ...  (Peter Eisentraut <peter_e@gmx.net>)
Responses RE: When malloc returns zero ...  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Re: When malloc returns zero ...  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: shmem_seq may be a bad idea
Next
From: Tom Lane
Date:
Subject: Re: RE: [PATCHES] relation filename patch