Re: can't stop autovacuum by HUP'ing the server
От | Alvaro Herrera |
---|---|
Тема | Re: can't stop autovacuum by HUP'ing the server |
Дата | |
Msg-id | 20080826161056.GG4920@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: can't stop autovacuum by HUP'ing the server ("Dave Cramer" <pg@fastcrypt.com>) |
Ответы |
Re: can't stop autovacuum by HUP'ing the server
|
Список | pgsql-hackers |
Dave Cramer wrote: > AutoVacuumShmem->av_signal[AutoVacForkFailed] = false; > pg_usleep(100000L); /* 100ms */ > > SendPostmasterSignal(PMSIGNAL_START_AUTOVAC_WORKER); > continue; > > Do these signals get cleaned up on a reload ? Well, not on a reload specifically, but this signal is of prompt response (i.e. the postmaster acts immediately on it). See CheckPostmasterSignal. Also, note that this code starts a worker, not the launcher which is what you're seeing. The signal you're looking for is PMSIGNAL_START_AUTOVAC_LAUNCHER (see the varsup.c code in the vicinity of what I posted earlier). The postmaster response is to set start_autovac_launcher (see sigusr1_handler in postmaster.c) and when this is seen set, the launcher is started (see ServerLoop in postmaster.c). However the bit you're interested in is *why* the signal is being sent, which is what the freeze limits determine. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-hackers по дате отправления: