On Wed, Apr 16, 2014 at 12:00 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-04-16 11:54:25 -0400, Tom Lane wrote:
>> Andres Freund <andres@2ndquadrant.com> writes:
>> > On 2014-04-16 11:37:47 -0400, Robert Haas wrote:
>> >> Why can't that be handled through ereport(ERROR/FATAL) rather than
>> >> through the choice of exit status?
>>
>> > I dislike that because it essentially requires the bgworker to have a
>> > full error catching environment like PostgresMain() has. That seems
>> > bad for many cases.
>>
>> That sounds like utter nonsense. No sane bgwriter code is going to be
>> able to discount the possibility of something throwing an elog(ERROR).
>> Now, you might not need the ability to do a transaction abort, but
>> you'll have to at least be able to terminate the process cleanly.
>
> Why? Throwing an error without an exception stack seems to work
> sensibly? The error is promoted to FATAL and the normal FATAL handling
> is performed? C.f. pg_re_throw() called via errfinish() in the ERRROR
> case.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company