On Wed, Apr 16, 2014 at 11:28 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
