| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Chris Purcell <chris(dot)purcell(dot)39(at)gmail(dot)com> |
| Cc: | pgsql-bugs(at)postgresql(dot)org, Sunir Shah <sunir(at)sunir(dot)org> |
| Subject: | Re: Unexpected chunk number |
| Date: | 2006-09-12 21:39:42 |
| Message-ID: | 22440.1158097182@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Chris Purcell <chris(dot)purcell(dot)39(at)gmail(dot)com> writes:
> Would the best advice be to get a pg_dump, then drop the database
> entirely and rebuild it?
>>
>> Definitely. It's entirely possible for pg_dump to dump successfully
>> from a database that still contains corruption. An example:
>> broken indexes on user tables. COPY just does a seqscan and never
>> looks
>> at the contents of indexes ...
> Just out of curiosity, why is it not possible to rebuild these
> indices entirely from scratch, dropping the defective file entirely,
> *without* reimporting into a fresh database?
See REINDEX. But my point was that there may be undetected corruption.
If I were you I'd not rely on REINDEX to prevent all problems.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chris Purcell | 2006-09-12 21:42:05 | Re: Unexpected chunk number |
| Previous Message | Chris Purcell | 2006-09-12 21:15:03 | Re: Unexpected chunk number |