2017-03-14 19:08 GMT+01:00 Robert Haas <robertmh...@gmail.com>:
> On Tue, Mar 14, 2017 at 3:31 AM, Pavel Stehule <pavel.steh...@gmail.com>
> > 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
> > 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
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company