Re: BUG #5439: Table crash after CLUSTER command - Mailing list pgsql-bugs

From Kevin Grittner
Subject Re: BUG #5439: Table crash after CLUSTER command
Date
Msg-id 4BD557930200002500030DCD@gw.wicourts.gov
Whole thread Raw
In response to BUG #5439: Table crash after CLUSTER command  ("Stefan Kirchev" <stefan.kirchev@gmail.com>)
Responses Re: BUG #5439: Table crash after CLUSTER command  (Stefan Kirchev <stefan.kirchev@gmail.com>)
List pgsql-bugs
"Stefan Kirchev" <stefan.kirchev@gmail.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

pgsql-bugs by date:

Previous
From: Scott Mead
Date:
Subject: Re: pgadmin supports on SLES10.3
Next
From: Tom Lane
Date:
Subject: Re: BUG #5439: Table crash after CLUSTER command