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: 4BD557930200002500030DCD@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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:

http://www.postgresql.org/docs/8.3/static/release

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.

-Kevin

In response to

Responses

Browse pgsql-bugs by date

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