Re: Preventing hangups in bgworker start/stop during DB shutdown - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Preventing hangups in bgworker start/stop during DB shutdown
Date
Msg-id CAGRY4nzHXR_VUi0Zk5o0qcwzWLm6Vz1oHg+k0Fn+2EP6+SXrZw@mail.gmail.com
Whole thread Raw
In response to Re: Preventing hangups in bgworker start/stop during DB shutdown  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 25 Dec 2020 at 06:07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wrote:
> Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.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.


Thanks for the change.

Cleanups like this in the BGW API definitely make life easier.

pgsql-hackers by date:

Previous
From: Yugo NAGATA
Date:
Subject: Re: Implementing Incremental View Maintenance
Next
From: Thomas Kellerer
Date:
Subject: Re: Why does creating logical replication subscriptions require superuser?