Preventing hangups in bgworker start/stop during DB shutdown

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Preventing hangups in bgworker start/stop during DB shutdown
Date: 2020-12-22 21:40:26
Message-ID: 661570.1608673226@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Here's an attempt at closing the race condition discussed in [1]
(and in some earlier threads, though I'm too lazy to find them).

The core problem is that the bgworker management APIs were designed
without any thought for exception conditions, notably "we're not
gonna launch any more workers because we're shutting down the database".
A process waiting for a worker in WaitForBackgroundWorkerStartup or
WaitForBackgroundWorkerShutdown will wait forever, so that the database
fails to shut down without manual intervention.

I'd supposed that we would need some incompatible changes in those APIs
in order to fix this, but after further study it seems like we could
hack things by just acting as though a request that won't be serviced
has already run to completion. I'm not terribly satisfied with that
as a long-term solution --- it seems to me that callers should be told
that there was a failure. But this looks to be enough to solve the
lockup condition for existing callers, and it seems like it'd be okay
to backpatch.

Thoughts?

regards, tom lane

[1] https://www.postgresql.org/message-id/flat/16785-c0207d8c67fb5f25%40postgresql.org

Attachment Content-Type Size
cancel-unserviced-worker-requests-1.patch text/x-diff 5.2 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-12-22 21:52:41 Re: libpq compression
Previous Message Bruce Momjian 2020-12-22 21:34:09 Re: Proposed patch for key managment