On Wed, Apr 16, 2014 at 12:28 PM, Andres Freund <andres@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 <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.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