On Fri, 14 Jan 2005, Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
>> 'k, this is looking promising ... but I'm a bit confused on the TOAST
>> tables ... I can't match on 'relname', since they aren't the same ... the
>> old has, for instance:
>> while the new has:
>> is there some sort of 'linkage' in pg_class that I'm not seeing?
> Yeah. A toast table's OID appears in the reltoastrelid field of its
> owning table. So you match new and old pg_class entries by name,
> take their reltoastrelid fields, look up those rows by OID, and their
> relfilenode fields give the names of the TOAST files.
'k, there is somewhere else that is 'holding' the information ... the
table in question is 'email' ... when I do a 'select, it tells me:
restore=# select * from email;
ERROR: could not open relation with OID 5773277
which is the treltoastrelid from the old:
restore=# select reltoastrelid from npg_class where relname = 'email';
but, for the new, it should be:
restore=# select reltoastrelid from pg_class where relname = 'email';
Is there something in the 'table file' itself that is holding that relid?
the only thing from the old, as far as system tables, taht I've copied
over is the pg_class file into the npg_class relid, so I don't think
there is anything else at the system catalog level that could
inadvertantly contain it ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2005-01-15 19:58:31|
|Subject: Re: FATAL: catalog is missing 1 attribute(s) for relid 16396 |
|Previous:||From: Greg Stark||Date: 2005-01-15 15:44:48|
|Subject: Re: sparse (static analyzer) report|