Re: bgworker crashed or not?
От | Craig Ringer |
---|---|
Тема | Re: bgworker crashed or not? |
Дата | |
Msg-id | 534F21E6.7080705@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: bgworker crashed or not? (Petr Jelinek <petr@2ndquadrant.com>) |
Ответы |
Re: bgworker crashed or not?
|
Список | pgsql-hackers |
On 04/17/2014 04:47 AM, Petr Jelinek wrote: > > Well the logging is just too spammy in general when it comes to dynamic > bgworkers but that's easy to fix in the future, no need to make > decisions for 9.4. Agreed - it's the *API* that we need sorted out for 9.4, and log output isn't something Pg tends to consider part of the API. > However I really don't like that I have to exit with exit code 1, which > is normally used as failure, if I want to shutdown my dynamic bgworker > once it has finished the work. And this behavior is something we can set > properly only once... As far as I can tell we have a couple of options: - Redefine what the exit codes mean so that exit 0 suppresses auto-restart and exits silently. Probably simplest. or - Expose a worker's BackgroundWorkerHandle as a global within the worker, and let it TerminateBackroundWorker(my_bgw_handle) its self. Of those, just changing the meaning of the exit code seems simpler and easier. It's not clear to me why it appears to be contentious. I don't think the status quo, with no way to exit a dynamic bgworker w/o an error, is OK. It's like those delightful "Error: Success" messages one gets when using perror() inappropriately - deeply confusing to users. Lets try not to be stuck with that when we can avoid it. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: