Re: can't stop autovacuum by HUP'ing the server - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: can't stop autovacuum by HUP'ing the server
Date
Msg-id 20080826161056.GG4920@alvh.no-ip.org
Whole thread Raw
In response to Re: can't stop autovacuum by HUP'ing the server  ("Dave Cramer" <pg@fastcrypt.com>)
Responses Re: can't stop autovacuum by HUP'ing the server  ("Dave Cramer" <pg@fastcrypt.com>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: can't stop autovacuum by HUP'ing the server
Next
From: "Dave Cramer"
Date:
Subject: Re: can't stop autovacuum by HUP'ing the server