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(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden