| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Borodin <amborodin(at)acm(dot)org>, amul sul <sulamul(at)gmail(dot)com> |
| Subject: | Re: background sessions |
| Date: | 2017-03-14 18:08:58 |
| Message-ID: | CA+TgmoafsO=RXh9mVDDmMQNYrPz+e33_Q0f2JMq1y4SeCz0=wA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 14, 2017 at 3:31 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-03-14 18:14:31 | Re: Write Ahead Logging for Hash Indexes |
| Previous Message | Robert Haas | 2017-03-14 17:58:51 | Re: Write Ahead Logging for Hash Indexes |