Skip site navigation (1) Skip section navigation (2)

Re: BUG #5439: Table crash after CLUSTER command

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Stefan Kirchev" <stefan(dot)kirchev(at)gmail(dot)com>, <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #5439: Table crash after CLUSTER command
Date: 2010-04-26 14:06:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
"Stefan Kirchev" <stefan(dot)kirchev(at)gmail(dot)com> wrote:
> PostgreSQL version: 8.3.3
> Description:        Table crash after CLUSTER command
> I order to keep good performance on tables CLUSTER is done
> regularly on each table every Sunday. Almost every time we loose a
> table which must be recreated afterward. The error yield is:
> pnp=# select * from  alcatel_bss_kpi_tmp.cs_hourly_kpi limit 1;
> ERROR:  could not open relation 1663/16404/2426042: No such file
> or directory
My first recommendation would be to apply the fixes for the bugs
found during the last two years by upgrading your executable to
8.3.10.  This does not require a dump and load, but if you have any
GiST indexes, or if you have hash indexes on intervals, you will
need to rebuild those indexes.  To get more details, see:
FWIW, we CLUSTER a few very small, very frequently updated tables
daily in about 100 databases to ensure that we recover from bloat
from the occasional long-running transaction, and we've *never*
seen this.
If you actually need to cluster *every* table *every* week, you
should review your vacuum policy.

In response to


pgsql-bugs by date

Next:From: Tom LaneDate: 2010-04-26 14:15:56
Subject: Re: BUG #5439: Table crash after CLUSTER command
Previous:From: Scott MeadDate: 2010-04-26 14:02:06
Subject: Re: pgadmin supports on SLES10.3

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group