Re: [HACKERS] Finding corrupt data

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Ed Loehr <ELOEHR(at)austin(dot)rr(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Matthew Hagerty <matthew(at)venux(dot)net>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Finding corrupt data
Date: 1999-12-16 17:31:10
Message-ID: 199912161731.MAA17285@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Bruce Momjian wrote:
>
> > > One RDBMS I used had a utility called 'dbcheck' which did some sort of
> > > examination of indices, tables, etc., and issued an 'OK' or 'CORRUPT' for
> > > each examined object. Such a utility for pgsql might simply do some
> > > combination of SELECT * or COPY TO as you suggest above.
> >
> > Does vacuum already do that?
>
> Not as far as I can tell. Here's the kind of output I see from vacuum:
>
> DEBUG: --Relation pg_class--
> DEBUG: Pages 10: Changed 0, Reapped 1, Empty 0, New 0; Tup 695: Vac 0, Keep/VTL
> 0/0, Crash 0, UnUsed 35, MinLen 102, MaxLen 132; Re-using: Free/Avail. Space
> 3828/0; EndEmpty/Avail. Pages 0/0. Elapsed 0/0 sec.
> DEBUG: Index pg_class_relname_index: Pages 16; Tuples 695: Deleted 0. Elapsed
> 0/0 sec.
> DEBUG: Index pg_class_oid_index: Pages 7; Tuples 695: Deleted 0. Elapsed 0/0
> sec.
>
> Am I missing something?

Vacuum does catch some problems, not all of them.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ed Loehr 1999-12-16 17:59:30 Re: [HACKERS] Finding corrupt data
Previous Message Ed Loehr 1999-12-16 17:29:32 Re: [HACKERS] Finding corrupt data