On Thu, 14 Sep 2000, Karl Schmid wrote:
> Here is a follow-up to my previous question
>
> I just looked up the other tables in the directory
> /hdb/psql/data/base/atha_snp (atha_snp being the name of the database). The
> content of the tables in this directory reflects the state before the crash, but
> the system files do not appear to be up do date (e.g., when issuing the
> \d command of psql).
>
> I guess the challenge is to update the system files to the tables.
>
> Any hints on solving this problem are greatly appreciated.
I'm not sure what of this will actually work (not having had to deal
with this kind of case).
First, you might be able to get away with moving the table file away,
doing a create table with exactly the same parameters and then moving
it back (and immediately doing a vacuum). This probably has potential
for badness, but if you immediately dump the table and the dump looks
good, you can try removing the table and restoring it from the dump.
Otherwise, you could try playing with the system tables, although you'd
want noone else accessing the server during that period, and you should
back up any other dbs just in case.
There's alot of stuff to change though. It may not be worth the potential
pain and suffering. I'm fairly certain you'll need a row in pg_class
and pg_type and a set of rows in pg_attribute (check the rows for other
tables as guides). You'll also probably want to make sure that there
aren't random errant rows pointing to the old oid (this could be in
pg_relcheck, pg_trigger, pg_index, pg_statistic, pg_attrdet -- and maybe
more -- These would need to be removed or changed to the new row)
You might need to make a row in pg_statistic, I'm not sure, although
I'd expect a vacuum analyze would do that for you.