Received: from localhost.localdomain (postgresql.org [64.49.215.8]) by localhost (Postfix) with ESMTP id 9B906476467 for ; Fri, 10 May 2002 12:48:23 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id B6A214763F2 for ; Fri, 10 May 2002 12:48:22 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g4AGmQW29204; Fri, 10 May 2002 12:48:26 -0400 (EDT) To: Ray Ontko Cc: nickf@ontko.com, pgsql-admin Subject: Re: A couple of errors encountered in 7.1.3=>7.2.1-2 data migration In-reply-to: <200205101635.LAA10840@shire.ontko.com> References: <200205101635.LAA10840@shire.ontko.com> Comments: In-reply-to Ray Ontko message dated "Fri, 10 May 2002 11:35:42 -0500" Date: Fri, 10 May 2002 12:48:26 -0400 Message-ID: <29201.1021049306@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200205/85 X-Sequence-Number: 4260 Ray Ontko writes: > develop=# select count(*) from temp_event ; > ERROR: cannot find attribute 1 of relation temp_event I'm beginning to think there is something seriously messed up about your installation. The simplest theory is that the indexes on pg_attribute are corrupted. You could try a query that won't use the indexes, eg select (select relname from pg_class where oid = attrelid) from pg_attribute where attnum = 1 order by 1; and look through the output to see if temp_event and the other broken table are mentioned. If so, then the rows are there but the index is wrong. You should be able to recover using REINDEX --- read the reference page for it carefully before executing the recovery procedure! If that doesn't work, re-initdb and re-importation of your dump would be a good next step. Something must have dropped a bit somewhere... regards, tom lane