Skip site navigation (1) Skip section navigation (2)

Re: can't stop autovacuum by HUP'ing the server

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Dave CramerDate: 2008-08-26 16:18:22
Subject: Re: can't stop autovacuum by HUP'ing the server
Previous:From: Alvaro HerreraDate: 2008-08-26 16:05:57
Subject: Re: can't stop autovacuum by HUP'ing the server

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group