On 09/07/2026 03:57, Fujii Masao wrote:
On Thu, Jul 9, 2026 at 6:57 AM Thom Brown <[email protected]> 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
