From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Jan Wieck <wieck(at)debis(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: When malloc returns zero ... |
Date: | 2000-05-01 21:17:51 |
Message-ID: | 1627.957215871@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-05-01 21:27:04 | Re: RE: [PATCHES] relation filename patch |
Previous Message | Tom Lane | 2000-05-01 21:08:26 | Re: shmem_seq may be a bad idea |