Re: How to kill a Background worker and Its metadata - Mailing list pgsql-hackers

From Akash Agrawal
Subject Re: How to kill a Background worker and Its metadata
Date
Msg-id CALF3U-41aT226Ufo3Psau+StfHA164eYPBK4rm6syJmvNqyPRA@mail.gmail.com
Whole thread Raw
In response to Re: How to kill a Background worker and Its metadata  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: How to kill a Background worker and Its metadata  (Craig Ringer <craig@2ndquadrant.com>)
List 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.paquier@gmail.com> wrote:
On Tue, Jun 28, 2016 at 3:27 AM, Akash Agrawal <aagrawa6@ncsu.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

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Postgres_fdw join pushdown - wrong results with whole-row reference
Next
From: Akash Agrawal
Date:
Subject: Re: How to kill a Background worker and Its metadata