Postgresql 属性编号10超过了列数0

此查询成功返回表中的所有行（大约850+）：

select * from my_db_log
 where date_trunc('day',creation_date) >= to_date('2014-03-05'::text,'yyyy-mm-dd');

但当我使用如下相同的查询添加

count（*）

时：

select count(*) from my_db_log
 where date_trunc('day',creation_date) >= to_date('2014-03-05'::text,'yyyy-mm-dd');

然后它返回给我：

********** Error **********

ERROR: attribute number 10 exceeds number of columns 0
SQL state: XX000

仅供参考：

creation\u date

是我表格的第10列

有趣的是，当我用

count（id）

替换

count（*）

时，它返回我

0

，但我的表中有符合条件的记录

编辑：我在整个数据库中尝试了

vacuumdb

命令，但它仍然不适用于我。下面是此特定表上的

vacuumdb

的详细输出

>vacuumdb --full --analyze -h 192.168.1.10 -p 8888 -U root -W --verbose --table my_db_log my_db
Password:

输出：

INFO:  vacuuming "public.my_db_log"
INFO:  "my_db_log": found 0 removable, 0 nonremovable row versions in 0 pages
DETAIL:  0 dead row versions cannot be removed yet.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  analyzing "public.my_db_log"
INFO:  "my_db_log": scanned 0 of 0 pages, containing 0 live rows and 0 dead rows; 0 rows in sample, 0 estimated total rows

---

你的数据库中有东西坏了。试一试

VACCUM-FULL分析我的数据库日志；

或者，更激进地说，从db服务器上的shell运行：

vacuumdb--full--analysismyu数据库

错误消息表示系统目录或其中一个相关索引中的损坏。在你做任何其他事情之前，先了解一下。小心不要丢失有价值的数据。

reindexdb——系统我的_数据库

---

如果没有任何帮助，要修复明显损坏的数据库，可以尝试删除整个集群，删除集群，创建新集群并恢复备份。还要确保找出是什么损坏了数据库。这通常不会发生（我从来没有发生过）。很可能，您正面临严重的硬件问题，在这种情况下，您需要尽快采取行动……

真空数据库对我不起作用。我已经用详细的输出更新了这个问题。但是，将表转储到另一个db中而不做任何更改是可行的。我没有看到在这个问题中提到850列。“行（大约850+）”对我来说是850行。但我不明白，如果vacuum声明表为空，第一个查询怎么会返回850行。@a_horse_和a_no_name:a right，谢谢。我误解了。删除了错误的评论。为什么shell命令“更激进”？doc说：“通过这个实用程序和其他访问服务器的方法清空和分析数据库之间没有任何有效的区别。”@exhuma：因为第二个选项清空整个数据库，而不仅仅是一个表。可能是一个损坏的索引。重建那张表上的索引有帮助吗？@a_horse_，没有名字，重新索引不起作用。但在执行转储/恢复后，问题就消失了。可能是我的数据库服务器中有一些损坏的文件系统！