Attribute number 10 exceeds number of columns 0

Question

This query returns all the rows(around 850+) from the table successfully:

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

But when I add the count(*) with the same query like below:

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

Then it returns me:

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

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

FYI: creation_date is the 10th column of my table.

Interestingly, when i replace count(*) with count(id) then it returns me 0 but I have records in my table those meet the condition.

EDITS: I tried the vacuumdb command over the whole database but still it is not working for me. Here is the verbose output for the vacuumdb on this particular table.

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

Output:

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

Answer 1

Something is broken in your database. Try

VACCUM FULL ANALYZE my_db_log;

Or, more radically, run from the shell on your db server:

vacuumdb --full --analyze my_database

Details in the manual.

The error message indicate breakage in the system catalog pg_attribute or one of the associated indices. Before you do anything else, read about corruption in the Postgres Wiki. Be very careful not to lose valuable data.
Then one other thing to try:

reindexdb --system my_database

If nothing helps, to repair your obviously broken DB, you could try to pg_dumpall the whole cluster, drop the cluster, create a new cluster and restore the backup. Also make sure you find out what broke your db. That does not usually happen (never happened to me, yet). Chances are, you are facing serious hardware problems, in which case you need to act soon ...