----- Original Message -----
> On 6.3.2012 21:24, Matteo Sgalaberni wrote:
> > Hi people!
> >
> > I have a pg 8.3. Today I issued in a database that comand:
>
> Which minor version? The last one in this branch is 8.3.18 and if
> you're
> running an old one, there might be an important bugfix ...
8.3.0, I read quickly all releases notes of 8.3.x and I didn't saw any fix that could be directly related to what is
happenedto me...there are issues related to ALTER TABLE but with other options like PRIMARY KEY or other parameters.
Are there fixes that could be related to what's happened to me?
> Not sure what you mean by 'physical data file of the cluster' but you
> should do a file-level backup of the whole cluster right now. Before
> trying to fix the issues (possibly damaging the data).
>
I copied the file of the filesystem that contain the table. (grep exampledata * and found the $file that contain the
tabledata).
On another server i did this:
CREATE TABLE cliente...
SELECT oid,relname from pg_class where relname = 'cliente';
cp $file $oid
cp $production_pg_clog local/pg_clog/
SELECT id,etc.... from table into tmp_table;
all my recovered data was into tmp_table
dumped the tmp_table and copied to the production server
> What do you mean by 'populated the table' with the production data?
> How
> did you do that?
on the production server:
ALTER TABLE cliente RENAME TO cliente_prova;
ALTER TABLE DROP CONSTRAINT etc.... (removed all foreign key that are pointing to cliente)
CREATE TABLE cliente ....
psql database < dumpof_tmp_table.sql
So I recovered the table cliente.
Now, if I try to drop the cliente_prova I receive the error posted in the previous email, and if I type the
\d cliente on psql, it return the schema twice of the table "cliente"...
For cleanup the situation I think that I need to remove the "old table" and repair the catalog that seems to be
damaged...
What do you suggest me?
Thanks!
Matteo
