Re: [HACKERS] background sessions
| От | Pavel Stehule | 
|---|---|
| Тема | Re: [HACKERS] background sessions | 
| Дата | |
| Msg-id | CAFj8pRCrLWHW+pCReaJPPy4UvjCXhpW162GFa7_FoVGXBfCxgg@mail.gmail.com обсуждение исходный текст  | 
		
| Ответ на | Re: [HACKERS] background sessions (Robert Haas <robertmhaas@gmail.com>) | 
| Ответы | 
                	
            		Re: [HACKERS] background sessions
            		
            		 | 
		
| Список | pgsql-hackers | 
2017-03-14 19:08 GMT+01:00 Robert Haas <robertmhaas@gmail.com>:
On Tue, Mar 14, 2017 at 3:31 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> Very often strategy can be recheck of parent process in some waiting
> cycles. It should not to impact performance.
I think that's going to be hard to arrange, and I think it isn't
necessary. If the leader wants to arrange for the worker to die when
it exits, it can use TerminateBackgroundWorker() from a
PG_ENSURE_ERROR_CLEANUP block or on_shmem_exit hook.
> I afraid so some waiting times in bg process can be high probable with this
> patch - and then is probable so somebody use pg_terminate_backend. This
> situation should not to finish by server restart.
I don't understand. The only way you'd need a server restart is if a
background process wasn't responding to SIGTERM, and that's a bug
independent of anything this patch does. It would be cause by the
background process not doing CHECK_FOR_INTERRUPTS() or the moral
equivalent regularly.
It is bug, and I don't know if it s this extension bug or general bug. 
There is not adequate cleaning after killing. 
How can be implemented pg_cancel_backend on background process if there are not CHECK_FOR_INTERRUPTS?
Regards
Pavel 
В списке pgsql-hackers по дате отправления: