Re: shared memory message queues

On Wed, Jan 15, 2014 at 4:32 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Jan 14, 2014 at 1:54 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
>> Robert Haas escribió:
>>> On Tue, Jan 14, 2014 at 12:43 PM, Thom Brown <thom(at)linux(dot)com> wrote:
>>> > LOG: worker process: test_shm_mq (PID 22041) exited with exit code 1
>>> > LOG: unregistering background worker "test_shm_mq"
>>>
>>> This is (perhaps unfortunately) required by the background-worker API.
>>> When a process exits with code 0, it's immediately restarted
>>> regardless of the restart-time setting. To get the system to respect
>>> the restart time (in this case, "never") you have to make it exit with
>>> code 1. It's been like this since the beginning, and I wasn't in a
>>> hurry to change it even though it seems odd to me. Perhaps we should
>>> revisit that decision.
>>
>> Yeah, it's probably better to do it now rather than waiting. When this
>> API was invented there wasn't any thought given to the idea of workers
>> that wouldn't be always up.
>
> Well, what do we want the semantics to be, then? Right now we have this:
>
> 0: restart immediately
> 1: restart based on the restart interval
With a 9.3 bgworker, restart interval is respected if exit code is
non-zero, worker exists immediately in case of ERROR or FATAL with
exit code 1.

> What should we have instead?
>
> I think it might be nice to have an exit code that means "never
> restart, regardless of the restart interval".
I imagine that to be useful, using 2 to avoid breaking currently
existing bgworkers. Perhaps it would be nicer to associate some error
flags directly in the bgworker API with something of the type:
#define BGW_EXIT_RESTART_NOW 0
#define BGW_EXIT_RESTART_INTERVAL 1
#define BGW_EXIT_STOP_FORCE 2
And all the other error codes could point by default to 1.
--
Michael