Received: from localhost (unknown [200.46.204.183])
	by developer.postgresql.org (Postfix) with ESMTP id 64A052E0050
	for <pgsql-admin-postgresql.org@developer.postgresql.org>;
	Fri,  2 May 2008 13:45:15 -0300 (ADT)
Received: from developer.postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 75005-07
	for <pgsql-admin-postgresql.org@developer.postgresql.org>;
	Fri,  2 May 2008 13:45:11 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by developer.postgresql.org (Postfix) with ESMTP id F35DE2E0045
	for <pgsql-admin@postgresql.org>; Fri,  2 May 2008 13:45:11 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m42Gj7tQ007452;
	Fri, 2 May 2008 12:45:08 -0400 (EDT)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Ian Westmacott <ianw@intellivid.com>, pgsql-admin@postgresql.org
Subject: Re: 8.1.8 autovacuum missing databases 
In-reply-to: <7391.1209746458@sss.pgh.pa.us> 
References: <1209574908.22509.6.camel@vega.intellivid.com>
	<20185.1209575233@sss.pgh.pa.us>
	<1209576488.22509.9.camel@vega.intellivid.com>
	<22093.1209588237@sss.pgh.pa.us>
	<1209646882.16174.15.camel@vega.intellivid.com>
	<7698.1209650248@sss.pgh.pa.us>
	<1209664799.16174.51.camel@vega.intellivid.com>
	<17328.1209667453@sss.pgh.pa.us>
	<1209668403.16174.60.camel@vega.intellivid.com>
	<17606.1209669106@sss.pgh.pa.us>
	<20080502161709.GH2320@alvh.no-ip.org>
	<7391.1209746458@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Fri, 02 May 2008 12:40:58 -0400"
Date: Fri, 02 May 2008 12:45:07 -0400
Message-ID: <7451.1209746707@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200805/23
X-Sequence-Number: 29107

I wrote:
> Perhaps it is worth adding a defense to autovac to not believe last
> autovac times that are in the future, since the system clock is not
> under our control and could go backwards.  Other than that I don't
> think there's any bug here.

Oh, the other thing that comes to mind is that it's a bad move not
to have exposed last_autovac_time anywhere in the pgstat views.
Obviously we cannot back-patch that, but I think it should be fixed
going forward.  This whole thing might've been much less of a mystery
if that state had been visible.

			regards, tom lane