Re: Configuring bgw_restart_time - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Configuring bgw_restart_time
Date
Msg-id CAMsr+YGvkgVf+Kau4PfpjOaR4dbuo2PP6+naw-93vKn_VskTrg@mail.gmail.com
Whole thread Raw
In response to Configuring bgw_restart_time  (Jeremy Finzel <finzelj@gmail.com>)
List pgsql-hackers
On Tue, 13 Aug 2019 at 20:37, Jeremy Finzel <finzelj@gmail.com> wrote:
I am working on an extension that uses background workers, and interested in adding code for it to auto-restart after a crash or server restart (similar to as-coded in worker_spi).

What pglogical does for this is use dynamic background workers with restart turned off. It does its own worker exit and restart handling from a manager worker that's an always-running static bgworker.

It's not ideal as it involves a considerable amount of extra work, but with BDR we rapidly found that letting postgres itself restart bgworkers was much too inflexible and hard to control. Especially given the issues around soft-crash restarts and worker registration (see thread https://www.postgresql.org/message-id/flat/534E6569.1080506%402ndquadrant.com) .

But I'm also interested in being able to configure bgw_restart_time using a GUC without having to restart the server, using only SIGHUP.  For example, I want to normally have the worker restart after 10 seconds.  But if I am doing maintenance on the server (without a db restart), I perhaps want to change this to -1 (BGW_NEVER_RESTART), kill the worker, do my business, then restart the worker.

Instead of doing that I suggest having a SQL-callable function that sets a flag in a shared memory segment used by the worker then sets the worker's ProcLatch to wake it up if it's sleeping. The flag can *ask* it to exit cleanly. If its exit code is 0 it will not be restarted.

You could also choose to have the worker exit with code 0 on SIGTERM, again causing itself to be unregistered and not restarted.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 2ndQuadrant - PostgreSQL Solutions for the Enterprise

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: progress report for ANALYZE
Next
From: Alvaro Herrera
Date:
Subject: Re: Problem while updating a foreign table pointing to a partitionedtable on foreign server