Re: worker_spi shouldn't execute again on sigterm

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: finzelj(at)gmail(dot)com, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: worker_spi shouldn't execute again on sigterm
Date: 2018-11-29 01:32:51
Message-ID: CAEepm=17txg-mFK-RRsivDijdS4GFk6Kyyw7YOrcOBqmPwxr9g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 29, 2018 at 2:11 PM Michael Paquier <michael(at)paquier(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-11-29 01:33:18 Re: Handling of REGRESS_OPTS in MSVC for regression tests
Previous Message Thomas Munro 2018-11-29 01:17:39 Re: minor typo in dsa.c