Is this a bug in auto vacuum worker?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Is this a bug in auto vacuum worker?

CNG L
In AutoVacWorkerMain(), the code calls on_shmem_exit(FreeWorkInfo,0) and then kill() to send SIGUSR2 to autovacuum launcher process. In FreeWorkInfo() it sets AutoVacuumShmem->av_signal[AutoVacRebalance] = true. But, is it possible that when autovacuum launcher’s SIGUSR2 handler checks av_signal[AutoVacRebalance], FreeWorkInfo() haven’t set this flag yet and thus autovacuum launcher will miss the AutoVacRebalance event?
Reply | Threaded
Open this post in threaded view
|

Re: Is this a bug in auto vacuum worker?

Michael Paquier-2
On Tue, Jan 08, 2019 at 10:47:01AM -0800, CNG L wrote:
> In AutoVacWorkerMain(), the code calls on_shmem_exit(FreeWorkInfo,0) and
> then kill() to send SIGUSR2 to autovacuum launcher process. In
> FreeWorkInfo() it sets AutoVacuumShmem->av_signal[AutoVacRebalance] = true.
> But, is it possible that when autovacuum launcher’s SIGUSR2 handler checks
> av_signal[AutoVacRebalance], FreeWorkInfo() haven’t set this flag yet and
> thus autovacuum launcher will miss the AutoVacRebalance event?

No, I don't think so.  There are a couple of instructions between the
moment SIGUSR2 is sent from the worker to the launcher for rebalancing
and the moment where on_shmem_exit() callbacks are called, still the
launcher gets aware of the death of the worker in ProcKill, so the
order of the events is right (double-checked manually as well):
1) Send SIGUSR2 from the worker to the launcher, asking for
rebalancing.
2) shmem callback is called.
3) launcher noticies the death of the worker, sees the signal, and
triggers the rebalancing.
--
Michael

signature.asc (849 bytes) Download Attachment