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
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

In response to

Responses

Browse pgsql-hackers by date

  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