From: | Akash Agrawal <aagrawa6(at)ncsu(dot)edu> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: How to kill a Background worker and Its metadata |
Date: | 2016-06-28 00:28:53 |
Message-ID: | CALF3U-41aT226Ufo3Psau+StfHA164eYPBK4rm6syJmvNqyPRA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I've handled SIGTERM signal. pg_terminate_backend send signals (SIGTERM) to
backend processes identified by process ID. And also, after this call I am
able to track in my logs that the background worker gets terminated.
Yet, I am only able to register first 8 background workers. I am using
select worker_spi1_launch(1) to launch it every time. This is why I guess
there is some metadata maintained which has got to be deleted.
On Mon, Jun 27, 2016 at 7:59 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:
> On Tue, Jun 28, 2016 at 3:27 AM, Akash Agrawal <aagrawa6(at)ncsu(dot)edu> wrote:
> > I've created a background worker and I am using Postgresql-9.4. This
> > bgworker handles the job queue dynamically and goes to sleep if there is
> no
> > job to process within the next 1 hour.
> >
> > Now, I want to have a mechanism to wake the bgworker up in case if
> someone
> > adds a new job while the bgworker is in sleep mode. So to do it, I have
> > created a trigger which initially removes the existing background worker
> and
> > then registers a new one. I am using the following two queries inside it:
>
> Why don't you just register and use a signal in this case? You could
> even do something with SIGHUP...
> --
> Michael
>
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2016-06-28 00:41:58 | Re: How to kill a Background worker and Its metadata |
Previous Message | Michael Paquier | 2016-06-27 23:59:46 | Re: How to kill a Background worker and Its metadata |