Re: Data problem - error "invalid attribute number # for <tablename>"

From: Sebastien Boisvert <sebastienboisvert(at)yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Data problem - error "invalid attribute number # for <tablename>"
Date: 2009-09-29 17:54:11
Message-ID: 221585.84480.qm@web34302.mail.mud.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

>
>>> Some poking through the source code finds only one match for that error
>>> message, which is in relcache.c. It looks like you have a row in
>>> pg_attribute that claims to belong to that relation, but has attnum
>>> 32533. It would be interesting to see the results for
>>> select * from pg_attribute where attrelid = 'largedata'::regclass
>>
>> [see attached]

>Hmm, no sign of any such row here ... try reindexing pg_attribute.

It gets more interesting:

MCS=# reindex table pg_attribute;
ERROR: could not access status of transaction 276828288
DETAIL: Could not open file "pg_subtrans/1080": No such file or directory.

Couldn't force the reindex, and vacuuming didn't help. I've checked the directory and there's only one file in it ('0004').

There's lots of previous info about that error, not none that I've found (yet) that have the same detail description (it usually says 'Invalid argument' instead). At this point this looks pretty serious, and unless there's a specific way to deal with this error (without hopefully running into other new ones), I might just go with our plan to recover the data using the backup, instead of spending more time on a possibly lost cause.

__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!

http://www.flickr.com/gift/

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2009-09-29 18:03:07 Re: Data problem - error "invalid attribute number # for <tablename>"
Previous Message Alvaro Herrera 2009-09-29 17:04:05 Re: Postgresql 8.4 pam