| From: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: FATAL: catalog is missing 1 attribute(s) for relid | 
| Date: | 2005-01-15 20:05:40 | 
| Message-ID: | 20050115160339.M16498@ganymede.hub.org | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Sat, 15 Jan 2005, Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
>> Is there something in the 'table file' itself that is holding that relid?
>
> Oh, drat, you're right --- TOAST pointer datums contain the OID of
> the toast file they are pointing to.  So any value wide enough to be
> pushed out-of-line is going to have a problem.
>
> Ugh.  Not sure there is any good way out of this one.  Adjusting the
> pointer datums in-place doesn't seem very feasible.
can I force the reuse of an OID?  for instance, if I were to get the 
map'ngs for those toast files, and then 'drop' the old database (I've got 
several backups of it already), can I insert those records into pg_class, 
with the proper OID?  Then again, OIDs don't have to be unique across 
databsaes, do they?  they are only serial ... so I should be able to just 
add those records into the new database, no?
----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org           Yahoo!: yscrappy              ICQ: 7615664
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-01-15 20:15:05 | Re: FATAL: catalog is missing 1 attribute(s) for relid 16396 | 
| Previous Message | Tom Lane | 2005-01-15 19:58:31 | Re: FATAL: catalog is missing 1 attribute(s) for relid 16396 |