On Fri, 14 Jan 2005, Tom Lane wrote:
> "Marc G. Fournier" <scrappy@postgresql.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:
>
>> pg_toast_5773565
>
>> while the new has:
>
>> pg_toast_8709712
>
>> 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'; reltoastrelid
--------------- 5773277
(1 row)
but, for the new, it should be:
restore=# select reltoastrelid from pg_class where relname = 'email'; reltoastrelid
--------------- 8709051
(1 row)
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@hub.org Yahoo!: yscrappy ICQ: 7615664