Обсуждение: 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): https://www.postgresql.org/message-id/flat/CAEepm%3D1c3hG1g3iKYwfa_PDsT49RBaBJsaot_qNhPSCXBm9rzA%40mail.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