On Wed, Apr 16, 2014 at 11:28 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> I actually think the right answer here might be to give background
>> workers a way to change their configured restart interval. We've
>> already got a shared memory area that the postmaster reads to know how
>> what to do when starting a dynamic background worker, so it probably
>> wouldn't be that hard. But I'm not volunteering to undertake that on
>> April 16th.
>
> That seems like a separate feature - and I don't see a need to rush that
> into 9.4. All I want that if we decide to change the API, we should do
> it now.
Well, I'm pretty OK with that, since I proposed it before and still
think it's important, but I'd rather leave it alone for another
release than rush into something we'll just end up changing again.
> What I dislike about the status quo is that the
> 1) The regular exit(0) behaves all but regular.
> 2) The only way to regularly exit is logged as a failure. Thus there's
> no real way to flag a failure that's actually a failure.
>
> So I think your proposal above already is an improvement upon the status
> quo.
I don't have time to write a patch for that, but I'm OK with
committing it (or having someone else commit it) even at this late
date, unless someone objects.
> Maybe we also should change the logging of bgworker exits.
It's pretty clear that the logging around bgworkers is way too verbose
for anything other than a long-running daemon, but I don't think we
should try to fix that problem right now. It needs more careful
thought than we have time to give it at this juncture. One idea might
be to let the registrant of the background worker specify a logging
level, or maybe just a flag bit to indicate verbose (LOG) or quiet
(say, DEBUG1 or DEBUG2) logging.
> I think we probably also need a way to exit that's treated as an error,
> but doesn't lead to a PANIC restart.
Why can't that be handled through ereport(ERROR/FATAL) rather than
through the choice of exit status? It seems to me that the only point
of the exit status is or should be to provide feedback to the
postmaster on how it should respond to the background worker's
untimely demise. If any other information needs to be conveyed, the
worker should log that itself rather than trying to tell the
postmaster what to log.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company