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 |
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 |