On Wed, Apr 16, 2014 at 12:11 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-04-16 12:04:26 -0400, Robert Haas wrote:
>> And... so what's the problem? You seemed to be saying that the
>> background worker would need to a more developed error-handling
>> environment in order to do proper logging, but here you're saying
>> (rightly, I believe) that it doesn't. Even if it did, though, I think
>> the right solution is to install one, not make it the postmaster's job
>> to try to read the tea leaves in the worker's exit code.
>
> Well, currently it will log the message that has been thrown, that might
> lack context. LogChildExit() already has code to print activity of the
> bgworker after it crashed.
I'm still not seeing the problem. It's the background worker's job to
make sure that the right stuff gets logged, just as it would be for
any other backend. Trying to bolt some portion of the responsibility
for that onto the postmaster is 100% wrong.
> Note that a FATAL error will always use a exit(1) - so we better not
> make that a special case in the code :/.
Well, everything's a special case, in that every error code has (and
should have) its own meaning. But the handling we give to exit code 1
is not obviously incompatible with what you probably want to have
happen after a FATAL.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
