On 2014-04-16 12:20:01 -0400, Robert Haas wrote:
> 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.
Well, it already has taken on that responsibility, it's not my idea to
add it. I merely want to control more precisely what happens.
> > 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.
That was essentially directed at Tom's proposal in
http://www.postgresql.org/message-id/32224.1391444962@sss.pgh.pa.us - I
don't think that'd be compatible with FATAL errors.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services