worker_spi shouldn't execute again on sigterm
I noticed that the way the test module worker_spi is written, it will
execute the main loop SQL one more time after it gets a sigterm, THEN exit
1. This was surprising to me where I used this module as a pattern for my
own background worker as I would have thought it should bail immediately
without executing any more SQL.
Shouldn't we add something like this line before it enters the phase where
it starts the transaction and executes the SQL?
/*
* In case of a SIGTERM, exit immediately
*/
if (got_sigterm)
{
break;
}
Please help me if I'm missing something.
Thanks,
Jeremy
On Wed, Nov 28, 2018 at 09:55:37AM -0600, Jeremy Finzel wrote:
I noticed that the way the test module worker_spi is written, it will
execute the main loop SQL one more time after it gets a sigterm, THEN exit
1. This was surprising to me where I used this module as a pattern for my
own background worker as I would have thought it should bail immediately
without executing any more SQL.Shouldn't we add something like this line before it enters the phase where
it starts the transaction and executes the SQL?
Yeah, I agree that this is a bad idea.
--
Michael
On Thu, Nov 29, 2018 at 2:11 PM Michael Paquier <michael@paquier.xyz> wrote:
On Wed, Nov 28, 2018 at 09:55:37AM -0600, Jeremy Finzel wrote:
I noticed that the way the test module worker_spi is written, it will
execute the main loop SQL one more time after it gets a sigterm, THEN exit
1. This was surprising to me where I used this module as a pattern for my
own background worker as I would have thought it should bail immediately
without executing any more SQL.Shouldn't we add something like this line before it enters the phase where
it starts the transaction and executes the SQL?Yeah, I agree that this is a bad idea.
You might also be interested in this thread about custom SIGTERM
handlers and loops like this (and some related topics):
/messages/by-id/CAEepm=1c3hG1g3iKYwfa_PDsT49RBaBJsaot_qNhPSCXBm9rzA@mail.gmail.com
The relevant TL;DR is that if you're calling anything non-trivial in
the loop, you might get stuck in wait syscall if you use a half-baked
SIGTERM handler that only knows how to exit your top level loop, but
prevents CHECK_FOR_INTERRUPTS() from detecting shutdown.
--
Thomas Munro
http://www.enterprisedb.com