Thread: Dumping database using 8.1 or 7.1

Hi!

I have a corrupt database that runs on Postgres 7.1.2. I was able to repair the database where I can now connect to the database and do queries.

I have a migration plan to transfer my database to a Postgres 8.1. I encountered problems when I was dumping the database. Postgres 7.1 reported: getTables(): SELECT (funcname) for trigger trig_mis_t_ins returned 0 tuples. Expected 1.

The trig_mis_t_ins trigger is no longer found on the database but it is still listed at the database. With this, I assume the database is corrupt.

Would my problems go away if I dump it on postgres 8?

Thanks.

Regards,

Jonathan

On 8/3/06, Jonathan Vallar <bamvallar.db@gmail.com> wrote:
> Hi!
>
>  I have a corrupt database that runs on Postgres 7.1.2. I was able to repair
> the database where I can now connect to the database and do queries.
>
>  I have a migration plan to transfer my database to a Postgres 8.1. I
> encountered problems when I was dumping the database. Postgres 7.1 reported:
> getTables(): SELECT (funcname) for trigger trig_mis_t_ins returned 0 tuples.
> Expected 1.
>
>  The trig_mis_t_ins trigger is no longer found on the database but it is
> still listed at the database. With this, I assume the database is corrupt.
>
>  Would my problems go away if I dump it on postgres 8?
>
>  Thanks.
>
>  Regards,
>
>  Jonathan
>

the better yu can do is try to dump the database with the 8.1's
pg_dump... but i don't know what problems can be (or if there is a
problem doing that)...

the better we can do is to wish you luck, your version is obsolete and
unsupported from some time ago...

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
                                       Richard Cook

Hi!

I was able to dump the corrupt database using Postgres 8.1. The pg_dump utility of 7.1 stops on errors.

Are there issues in using pg_dump for Postgres 8.1 to a database created in Postgres 7.1?

After dumping the database. I tried to load it on Postgres 8.1. I encountered errors on some database tables. Some lines on the file are empty (a blank record or a corrupt record?). Before the said lines, there was a "\M". What does "\M" stand for?

Thanks in advance.

Regards,

Jonathan

"Jonathan Vallar" <bamvallar.db@gmail.com> writes:
> After dumping the database. I tried to load it on Postgres 8.1. I
> encountered errors on some database tables. Some lines on the file are empty
> (a blank record or a corrupt record?). Before the said lines, there was a
> "\M". What does "\M" stand for?

Carriage return --- you evidently have some Mac- or Windows-style
newlines in your data.  My recollection is that 7.1 had a different
convention for representing these in COPY data than the later versions
do.  If you want to preserve them exactly as-is you might try doing
the pg_dump from 7.1 with the dump-data-as-INSERTs option. If you'd
rather clean up the data then just manually remove the CRs from the dump
file ...

            regards, tom lane

Jonathan Vallar wrote:
> Thanks sir.
>
> Is it safe to use the Postgres 8.1.4 pg_dump utility to dump data from a
> postgres 7.1.2 database?

Yes.


--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Hi guys!

I was able to dump my database created on Postgres 7.1.2 to Postgres  8.1.4 .

It was a little hassle though because I have to manually remove "\M" from the dump file. This is manageable.

I am stucked though with one problem

psql:si_t2:36: ERROR:  missing data for column "remarks"
CONTEXT: COPY si_t2, line 145:  <some data>

Upon checking line 145, there are no weird characters. Upon checking the whole dump file, the db dump still containts


Sample data:
"jonathan \"
"           "

I manually removed "\" and the new line. The problem still persists. According to the table schema, the "remarks" field allows blank or null values.


The database already has missing triggers and also has missing stored procedures. I assume, some tables are corrupted. The pg_dump of postgres 7.1.2 is unable to dump the db tables, triggers and stored procs.
The pg_dump utility returns an error that it cannot dump missing triggers but are still at the database catalogue.



Does this mean that I really cannot dump my database?

Thanks!

Regards,

Jonathan

"Jonathan Vallar" <bamvallar.db@gmail.com> writes:
> I am stucked though with one problem

> psql:si_t2:36: ERROR:  missing data for column "remarks"
> CONTEXT: COPY si_t2, line 145:  <some data>

This basically means that the data line hasn't got the right number of
column separators.  Count the tabs ...

            regards, tom lane

>  It was a little hassle though because I have to manually remove "\M" from
> the dump file. This is manageable.
>
>  I am stucked though with one problem
>  psql:si_t2:36: ERROR: missing data for column "remarks"
> CONTEXT: COPY si_t2, line 145: <some data>
>
> Upon checking line 145, there are no weird characters. Upon checking the
> whole dump file, the db dump still containts
>
>
> Sample data:
> "jonathan \"
> " "
>

maybe data was:
"jonathan \N"

and that "\N" means a null value in COPY dialect...

--
regards,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
                                       Richard Cook