On Wed, Apr 16, 2014 at 12:00 PM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2014-04-16 11:54:25 -0400, Tom Lane wrote: >> Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
