Re: BUG #5439: Table crash after CLUSTER command
От | Kevin Grittner |
---|---|
Тема | Re: BUG #5439: Table crash after CLUSTER command |
Дата | |
Msg-id | 4BD557930200002500030DCD@gw.wicourts.gov обсуждение исходный текст |
Ответ на | BUG #5439: Table crash after CLUSTER command ("Stefan Kirchev" <stefan.kirchev@gmail.com>) |
Ответы |
Re: BUG #5439: Table crash after CLUSTER command
|
Список | 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 по дате отправления: