On 2014-04-16 12:20:01 -0400, Robert Haas wrote:
> On Wed, Apr 16, 2014 at 12:11 PM, Andres Freund <and...@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.1391444...@sss.pgh.pa.us - I
don't think that'd be compatible with FATAL errors.


Andres Freund

 Andres Freund                     http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to