"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> which there are more then 3 attributes ... but, of course, there is
> nothing for the one I just manually added to pg_class ... should this just
> be duplicated for 5773277?
No, just do
update pg_attribute set attrelid = 5773277 where attr
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> belay that one ... my error, wasn't doin ghte reindex right ... fixed the
> pg_class issue, but still have one with the email table itself in
> multi-user:
> restore=# select * from email;
> ERROR: catalog is missing 3 attribute(s) for relid 5773
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> backend> reindex pg_class;
> ERROR: syntax error at or near "pg_class" at character 9
"reindex table pg_class", I think. And you'll probably need to be doing
this in a backend started with -P command line option.
regards,
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Hrmmm ... how about if I pg_dump --oids pg_class, make the modes and then
> reload it as opg_class, shut down the database server and move opg_class
> over pg_class, after making the required modifications to opg_class?
Good idea. Give it a shot.
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> 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?
I
"Marc G. Fournier" <[EMAIL PROTECTED]> 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
"Marc G. Fournier" <[EMAIL PROTECTED]> 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 som
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> course that won't work, since its link'd to the oid of the table name :(
> whose idea was this "let's name the files by the OID" again? :(
Actually, I think you can make this work, if you are sure of the schema
of the old database. Try something l
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> course that won't work, since its link'd to the oid of the table name :(
Not to mention all the other system catalogs. You could maybe make this
idea work by regenerating the entire catalog set, but not by
regenerating just pg_attribute. But if y
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> What the client did was a 'delete from pg_attribute where ... ' ...
[ blink... ] Well, that sort of thing is definitely a candidate for the
Darwin Award, but what exactly was the WHERE clause?
> The database is a 7.4.2 one ... my first thought was
Did some searching, and figured/concluded that things are pretty much
hosed ... the last backup is from June (clients machine, not ours), but
before I suggest going back to that backup, I want to make sure that I
haven't overlooked anything ...
What the client did was a 'delete from pg_attribut
11 matches
Mail list logo
