On 09/07/2026 03:57, Fujii Masao wrote:
> On Thu, Jul 9, 2026 at 6:57 AM Thom Brown <thom@linux.com> wrote:
>> @@ -724,6 +725,14 @@ InitAuxiliaryProcess(void)
>> */
>> PGSemaphoreReset(MyProc->sem);
>>
>> + /* Some aux processes are also advertised in ProcGlobal */
>> + if (MyBackendType == B_AUTOVAC_LAUNCHER)
>> + pg_atomic_write_u32(&ProcGlobal->avLauncherProc, MyProcNumber);
>>
>> I'm looking for the places this gets called from. I can only see
>> auxprocess.c which the launcher doesn't go through. The same question
>> for similar code in AuxiliaryProcKill().
>
> You're right. The autovacuum launcher does not go through
> AuxiliaryProcessMainCommon(), so it never calls
> InitAuxiliaryProcess(). Instead, it initializes its PGPROC with
> InitProcess().
>
> As a result, the avLauncherProc assignment added to
> InitAuxiliaryProcess() is never executed for the launcher, and the
> corresponding cleanup in AuxiliaryProcKill() is never reached either.
Huh, you're right. That raises some questions:
Why is the autovacuum launcher not an aux process? I guess it's because
it needs to acquire a heavy-weight lock in order to read the list of
databases.
How come none of the tests failed? I guess the path to wake up the
launcher isn't critical for correctness, it just makes autovacuum slower
to react.
> It seems we should move the avLauncherProc set/clear operations to
> InitProcess()/ProcKill() path, as in the attached patch.
Thanks! Committed that, and also Nathan's volatile removal.
- Heikki
