Tom Lane wrote: > Alvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx> 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.
