Re: Corrupt database? 8.1/FreeBSD6.0

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Amiel <becauseimjeff(at)yahoo(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Corrupt database? 8.1/FreeBSD6.0
Date: 2007-01-12 14:38:07
Message-ID: 20070112143807.GA27743@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-patches

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2007-01-12 14:47:55 Re: [HACKERS] Checkpoint request failed on version 8.2.1.
Previous Message Tom Lane 2007-01-12 14:33:57 Re: [HACKERS] Checkpoint request failed on version 8.2.1.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-01-12 14:39:34 Re: to_char not IMMUTABLE?
Previous Message Tom Lane 2007-01-12 14:33:57 Re: [HACKERS] Checkpoint request failed on version 8.2.1.

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2007-01-12 14:52:57 Re: Corrupt database? 8.1/FreeBSD6.0
Previous Message Tom Lane 2007-01-12 14:16:23 Re: Corrupt database? 8.1/FreeBSD6.0