On Wed, Apr 16, 2014 at 12:28 PM, Andres Freund <and...@2ndquadrant.com> wrote: > 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.s
I think that's doubling down on an already-questionable design principle. Or if I may be permitted a more colloquial idiom: Luke, it's a trap. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers