Thread: Re: When malloc returns zero ...
Tom Lane writes: > elog(ERROR) doesn't work in the postmaster. Well, it does "work", but > it just prints the message and then exit()s. That might be good > enough for errors detected during postmaster startup, Exactly. > but I'd hate to see it called after the postmaster is up and running. That's why I don't do it. > Sooner or later we will probably want to fix things so that > elog(ERROR) in the postmaster returns control to the postmaster's idle > loop, much like elog() in a backend works. 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. In many cases printing an error message and returning a failure value to the caller to let it deal with it is much easier for both parties. However, there's no way to print an error message and continuing execution unless you either label it 'DEBUG' or use fprintf. It's furthermore equally impossible to communicate an error message to the server log and not have it sent to the front-end. This tprintf business apparently tried to work around that but it was only painting over symptoms and added to the confusion along the way. > 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. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
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
> -----Original Message----- > From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On > Behalf Of Tom Lane > > 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. I agree with Peter at this point. For example,even basic functions call elog() easily but we can't catch the error and we(at least I) couldn't call basic functions easily. In fact I suffered very much to avoid elog() call in order to enable dropping tables whose base relation files has already been removed Regards. Hiroshi Inoue Inoue@tpf.co.jp
On Mon, 1 May 2000, Tom Lane wrote: > Er, what's wrong with elog(DEBUG)? Well, it says "DEBUG", not "ERROR", that's all. I'm using this in fact but it's suboptimal. > 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? Good that you mention that ... :) > 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. So you can set buffers, max backends, and that sort of static stuff. I think that each backend reading the config file on startup is unnecessarily slow. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Hiroshi Inoue wrote: > > > -----Original Message----- > > From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On > > Behalf Of Tom Lane > > > > 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. > > I agree with Peter at this point. > For example,even basic functions call elog() easily but we can't > catch the error and we(at least I) couldn't call basic functions > easily. In fact I suffered very much to avoid elog() call in order > to enable dropping tables whose base relation files has already > been removed The current model is also problematical in the case of procedural languages as well. Many times, when there is an error, both the backend and the PL handler needs to do cleanup. But it is very hard for the PL handler to 'capture' the exception in order to do the cleanup. Witness the ingenious lengths Jan had to go to, to do it in pltcl. I've tried to do the same in plperl but am not convinved that it is correct. And even if I get it correct, maintainability suffers greatly. -- Mark Hollomon mhh@nortelnetworks.com ESN 451-9008 (302)454-9008
>> I agree with Peter at this point.
>> For example,even basic functions call elog() easily but we can't
>> catch the error and we(at least I) couldn't call basic functions
>> easily. In fact I suffered very much to avoid elog() call in order
>> to enable dropping tables whose base relation files has already
>> been removed
> The current model is also problematical in the case of procedural
> languages as well. Many times, when there is an error, both
> the backend and the PL handler needs to do cleanup. But it
> is very hard for the PL handler to 'capture' the exception in
> order to do the cleanup.
It would be fairly easy to extend the existing setjmp/longjmp support
to allow multiple layers of code to catch an elog(ERROR) on its way
out to the outer loop. That might be a better answer for things like
PL handlers than the current approach, which is basically "any cleanup
you need, you'd better be prepared to do as part of transaction abort
processing".
(BTW, I actually think that the current approach is more robust than
exception catchers for modules that are part of the standard system;
it forces on you the discipline of making sure that all recoverable
resources are tracked in data structures less transient than some
routine's local variables. But it's no help for add-on modules like
PL handlers, because they don't get called during transaction abort.
A partial answer might be to add a hook to allow add-ons to get called
during commit or abort cleanup?)
But if we did add support for multiple layers of longjmp catching,
the only thing that would really work in general would be for an
error catcher to do local cleanup and then pass the error on outwards
(possibly changing the error message). It would not be safe to catch
the error and then continue as if nothing had happened. There is too
much code that assumes that it doesn't have to leave things in a
particularly clean state when it elog()s, because transaction abort
will clean up after it. Fixing *that* would be a really major task,
and a perilous one.
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > >> I agree with Peter at this point. > >> For example,even basic functions call elog() easily but we can't > >> catch the error and we(at least I) couldn't call basic functions > >> easily. In fact I suffered very much to avoid elog() call in order > >> to enable dropping tables whose base relation files has already > >> been removed > > > The current model is also problematical in the case of procedural > > languages as well. Many times, when there is an error, both > > the backend and the PL handler needs to do cleanup. But it > > is very hard for the PL handler to 'capture' the exception in > > order to do the cleanup. > > It would be fairly easy to extend the existing setjmp/longjmp support > to allow multiple layers of code to catch an elog(ERROR) on its way > out to the outer loop. That might be a better answer for things like > PL handlers than the current approach, which is basically "any cleanup > you need, you'd better be prepared to do as part of transaction abort > processing". > > (BTW, I actually think that the current approach is more robust than > exception catchers for modules that are part of the standard system; > it forces on you the discipline of making sure that all recoverable > resources are tracked in data structures less transient than some > routine's local variables. Hmm,for the query SELECT .. FROM .. WHERE int2key = 1; we coudn't try to convert 1 -> 1::int2 because the conversion may cause elog(ERROR). Isn't it too restrictive ? Comments ? Hiroshi Inoue Inoue@tpf.co.jp
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>> (BTW, I actually think that the current approach is more robust than
>> exception catchers for modules that are part of the standard system;
>> it forces on you the discipline of making sure that all recoverable
>> resources are tracked in data structures less transient than some
>> routine's local variables.
> Hmm,for the query SELECT .. FROM .. WHERE int2key = 1;
> we coudn't try to convert 1 -> 1::int2 because the conversion may
> cause elog(ERROR). Isn't it too restrictive ?
Well, that's not a particularly good example, because it wouldn't
be hard at all for us to avoid reducing "int2var = 32768::int4"
to "int2var = 32768::int2" (oops). The reason the optimizer is
presently staying away from this sort of thing is that it isn't
sure whether it's safe to reduce, say, "int2var + 32767::int4"
to "int2var + 32767::int2" (maybe oops, maybe OK, but for sure
the absence of elog during the constant-reduction doesn't tell
you enough). AFAICS we need a whole lot of datatype-and-operator-
specific semantic knowledge to be able to do that kind of reduction
safely.
As things currently stand, you could catch an elog() escape and not
propagate the error *if* you had carefully analyzed all the possible
errors that would be generated by the piece of code you intend to call
and figured out that they were all "safe". That strikes me as both a
ticklish analysis to begin with and horribly subject to future breakage,
for any but the most trivial of called routines. int2eq is perhaps
simple enough to be analyzed completely ;-) ... but the approach
doesn't scale.
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > >> (BTW, I actually think that the current approach is more robust than > >> exception catchers for modules that are part of the standard system; > >> it forces on you the discipline of making sure that all recoverable > >> resources are tracked in data structures less transient than some > >> routine's local variables. > > > Hmm,for the query SELECT .. FROM .. WHERE int2key = 1; > > we coudn't try to convert 1 -> 1::int2 because the conversion may > > cause elog(ERROR). Isn't it too restrictive ? > > Well, that's not a particularly good example, because it wouldn't > be hard at all for us to avoid reducing "int2var = 32768::int4" > to "int2var = 32768::int2" (oops). Hmm,am I misunderstanding ? As for conversion functions,shouldn't they return return-code unless they could throw "catchable" exceptions ? If the conversion 32768::int4 -> 32768::int2 returns an error we would be able to find that "int2var = 32768::int4" is always false. If I recognize correctly,"catchable" exceptions means that we could catch them if we want(otherwise they are dealt with a default exception handler like current elog handler). So they would be same as elog() except the special cases we are interested in. Where are problems when we handle conversion functions with return code or "catchable" exceptions ? Regards. Hiroshi Inoue Inoue@tpf.co.jp