From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Dave Cramer <pg(at)fastcrypt(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: can't stop autovacuum by HUP'ing the server |
Date: | 2008-08-26 16:10:56 |
Message-ID: | 20080826161056.GG4920@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2008-08-26 16:18:22 | Re: can't stop autovacuum by HUP'ing the server |
Previous Message | Alvaro Herrera | 2008-08-26 16:05:57 | Re: can't stop autovacuum by HUP'ing the server |