| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> | 
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> | 
| Subject: | Re: Preventing hangups in bgworker start/stop during DB shutdown | 
| Date: | 2020-12-24 22:07:43 | 
| Message-ID: | 1077540.1608847663@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
I wrote:
> Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> writes:
>> 4) IIUC, in the patch we mark slot->terminate = true only for
>> BGW_NEVER_RESTART kind bg workers, what happens if a bg worker has
>> bgw_restart_time seconds and don't we hit the hanging issue(that we
>> are trying to solve here) for those bg workers?
> The hang problem is not with the worker itself, it's with anything
> that might be waiting around for the worker to finish.  It doesn't
> seem to me to make a whole lot of sense to wait for a restartable
> worker; what would that mean?
Upon further looking around, I noted that autoprewarm's
autoprewarm_start_worker() function does that, so we can't really
dismiss it.
However, what we can do instead is to change the condition to be
"cancel pending bgworker requests if there is a waiting process".
Almost all of the time, that means it's a dynamic bgworker with
BGW_NEVER_RESTART, so there's no difference.  In the exceptional
cases like autoprewarm_start_worker, this would result in removing
a bgworker registration record for a restartable worker ... but
since we're shutting down, that record would have no effect before
the postmaster exits, anyway.  I think we can live with that, at
least till such time as somebody redesigns this in a cleaner way.
I pushed a fix along those lines.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro Horiguchi | 2020-12-25 00:12:52 | Re: In-placre persistance change of a relation | 
| Previous Message | Tom Lane | 2020-12-24 18:04:44 | Re: Better client reporting for "immediate stop" shutdowns |