Re: Wake up autovacuum launcher from postmaster when a worker exits

On 09/01/2026 00:20, Nathan Bossart wrote:
> On Thu, Jan 08, 2026 at 09:57:38PM +0200, Heikki Linnakangas wrote:
>> * It makes it consistent with background workers. When a background worker
>> exits, the postmaster sends the signal to the launching process (if
>> requested).
> 
> I've wondered about making autovacuum workers proper background workers.

Yeah, me too...

>> I'm a little surprised it wasn't done this way to begin with, so I wonder if
>> I'm missing something?
> 
> This code dates back to commit e2a186b03c.  I skimmed through the nearby
> thread [0] and didn't immediately notice any discussion about this.  My
> guess is that it seemed simpler to directly alert the launcher, since it's
> the one that needs to take action.
> 
> [0] https://postgr.es/m/flat/20070404233954.GK19251%40alvh.no-ip.org

Thanks for checking. I suspect we wanted to keep postmaster as dumb as 
possible, having all logic in the child process if at all possible. But 
we perhaps went a little overboard with that; signaling child processes 
seems squarely like postmaster's core business.

On 09/01/2026 10:27, li carol wrote:
>> On Thu, Jan 8, 2026 at 11:57 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>>
>>> When an autovacuum worker exits, ProcKill() sends SIGUSR2 to the
>>> launcher. I propose moving that responsibility to the postmaster, because:
>>>
>>> * It's simpler IMHO
>>>
>>> * The postmaster is already responsible for sending the signal if
>>> fork() fails
>>>
>>> * It makes it consistent with background workers. When a background
>>> worker exits, the postmaster sends the signal to the launching process
>>> (if requested).
>>>
>>> * Postmaster doesn't need to worry about sending the signal to the
>>> wrong process if the launcher's PID is reused, because it always has
>>> up-to-date PID information, because the launcher is postmaster's child
>>> process. That risk was negligible to begin with, but this eliminates
>>> completely, so we don't need the comment excusing it it anymore.
>>
>> It sounds reasonable to me too. +1.
> 
> I have completed the testing for this patch with a focus on the signaling logic from postmaster to launcher.
> 
> ...
> 
> This confirms that the postmaster successfully notifies the launcher and the worker slot is freed appropriately before the notification.
> 
> The patch looks correct and robust. +1 from my side.

Committed, thanks for the reviews and testing!

- Heikki