From: | bower(at)image(dot)Kodak(dot)COM (J Christopher Bower) |
---|---|
To: | pgsql-general(at)postgreSQL(dot)org |
Subject: | Database corruption - postgres 6.3.2 |
Date: | 1998-08-26 18:24:18 |
Message-ID: | 199808261824.OAA20370@coyote.image.Kodak.COM |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I recently upgraded to Postgres 6.3.2 from 6.1 in a test environment. All tables
were accessible until this morning, when I discovered that one frequently read
tables was corrupted.
Performing a select on the table in psql resulted in the following error:
FATAL: unrecognized data from the backend. It probably dumped core.
Since the backend failed, no other commands would process from that point on.
To see what would happen I tried a pg_dump on the database and the following
message was displayed:
SQL query to dump the contents of Table ilsl_color_content did not execute
correctly. After we read all the table contents from the backend, PQendcopy()
failed. Explanation from backend: 'Error return detected from backend, but
attempt to read the message failed.'.
The query was: 'COPY ilsl_color_content TO stdout;
I then decided to \copy the table to a file and look at it. The copy did not
fail, but only part of the table was copied.
I then vacuumed the database, which was no done since the upgrade was preformed,
and the following message was displayed:
Rel ilsl_color_content: Uninitialized page 6 - fixing
After the vacuum, the corrupted table was accessible.
I would like to know what happened or where to look for answers. Is this type
of behavior typical with 6.3.2? I don't remember any problems like this with
6.1.
Lately, I have noticed several messages regarding the backend failing, and was
wondering if anyone else has had similar experiences?
Thanks in advance for your assistance.
Chris Bower
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Flanders | 1998-08-26 21:22:41 | Using Pg's error message |
Previous Message | Mark W. Linvill | 1998-08-26 15:15:54 | 6.3.2 Y2K Compliance |