Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Hmm, that would mean an ANALYZE got done on template0, no? ... but
> > AFAICT process_whole_db() always sets analyze=false.
>
> The thing that's bothering me is that I don't see any certainty that
> template0 is only processed via the process_whole_db() path. In the
> 8.1 code, the existence of a stats-collector DB entry causes a DB
> to enter the normal round-robin processing path ... and I'm wondering
> whether the mere act of autovac connecting due to process_whole_db()
> doesn't cause such an entry to come into existence.
Hmm, as far as I can tell, the database entry would not be created
merely by a vacuum. The only way to create a database entry in pgstat
is by calling pgstat_recv_tabstat(); and pgstat_report_tabstat is only
called in postgres.c (not invoked via autovacuum) and in
pgstat_beshutdown_hook (not sure if this one is).
So I agree that there is a risk if the user connects to template0 and
the database pgstat entry gets created -- but that doesn't seem to be
the case here.
Confirmation on which table is causing the trouble would be good.
> 8.2's approach is saner but I think we need some sort of band-aid
> in the 8.1 branch...
Maybe we could forcibly activate the freeze mode on a template database?
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.