Обсуждение: How to kill a Background worker and Its metadata
Hi,
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:
select pg_terminate_backend(pid of bgworker);
select worker_spi1_launch(1);
I am retrieving the pid from pg_Stat_activity. The maximum number of background worker that can run simultaneously is equal to 8. I think even if I call pg_terminate_backend the metadata of the background worker is not being deleted and as a result after 8 insert operations I am not able to register a background worker. Please suggest what can be done here.
Best,
Akash
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
On 28 June 2016 at 02:27, Akash Agrawal <aagrawa6@ncsu.edu> wrote:
Hi,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.
Don't do that.
Instead, set the background worker's process latch, which you can find in the PGPROC array. There are a variety of examples of how to set latches in the sources.
I am retrieving the pid from pg_Stat_activity. The maximum number of background worker that can run simultaneously is equal to 8. I think even if I call pg_terminate_backend the metadata of the background worker is not being deleted
Correct. Unless you register it as a dynamic bgworker with no automatic restart, it'll get restarted when it exits uncleanly.
Have the worker call proc_exit(0) if you want it not to be restarted.
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
I am calling proc_exit(1) once the worker encounters SIGTERM signal. I've attached my code here.
Here is the link to stackoverflow:
On Mon, Jun 27, 2016 at 8:41 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
On 28 June 2016 at 02:27, Akash Agrawal <aagrawa6@ncsu.edu> wrote:Hi,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.Don't do that.Instead, set the background worker's process latch, which you can find in the PGPROC array. There are a variety of examples of how to set latches in the sources.I am retrieving the pid from pg_Stat_activity. The maximum number of background worker that can run simultaneously is equal to 8. I think even if I call pg_terminate_backend the metadata of the background worker is not being deletedCorrect. Unless you register it as a dynamic bgworker with no automatic restart, it'll get restarted when it exits uncleanly.Have the worker call proc_exit(0) if you want it not to be restarted.--
Вложения
On 28 June 2016 at 08:28, Akash Agrawal <aagrawa6@ncsu.edu> wrote:
I've handled SIGTERM signal.pg_terminate_backendsend 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.
(Please reply below other posts, not above)
* proc_exit(0) from within the worker; or
* register it with BGW_NO_RESTART so it doesn't auto-restart in the first place.
This is a deficiency in the bgworker API, but there are workarounds in place and other things are more important for now. Just make your your workers proc_exit(0) on SIGTERM or don't register them as auto-restarting.