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> > 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 > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
