Re: [HACKERS] background sessions - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] background sessions
Date
Msg-id CA+TgmoafsO=RXh9mVDDmMQNYrPz+e33_Q0f2JMq1y4SeCz0=wA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] background sessions  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [HACKERS] background sessions  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Write Ahead Logging for Hash Indexes
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Write Ahead Logging for Hash Indexes