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. Greetings, 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: http://www.postgresql.org/mailpref/pgsql-hackers