| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Paul B(dot) Anderson" <paul(dot)a(at)pnlassociates(dot)com> |
| Cc: | "[ADMIN]" <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: Vacuum error on database postgres |
| Date: | 2006-09-01 14:41:09 |
| Message-ID: | 4001.1157121669@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin pgsql-hackers |
"Paul B. Anderson" <paul(dot)a(at)pnlassociates(dot)com> writes:
> I did delete exactly one of each of these using ctid and the query then
> shows no duplicates. But, the problem comes right back in the next
> database-wide vacuum.
That's pretty odd --- I'm inclined to suspect index corruption.
> I also tried reindexing the table.
Get rid of the duplicates (actually, I'd just blow away all the
pg_statistic entries for each of these tables) and *then* reindex.
Then re-analyze and see what happens.
Worst case you could just delete everything in pg_statistic, reindex it,
do a database-wide ANALYZE to repopulate it. By definition there's not
any original data in that table...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Paul B. Anderson | 2006-09-01 15:04:36 | Re: Vacuum error on database postgres |
| Previous Message | Luís Sousa | 2006-09-01 14:40:09 | Problem using pg_restore with -a option |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-09-01 14:45:09 | Re: DOC: catalog.sgml |
| Previous Message | Bricklen Anderson | 2006-09-01 14:39:45 | Re: [pgsql-advocacy] Thought provoking piece on NetBSD |