Hi,
On running pg_dump, I am consistently getting the following errors:
pg_dump: ERROR: unexpected chunk number 2 (expected 0) for toast
value 223327
pg_dump: SQL command to dump the contents of table "pagecache"
failed: PQendcopy() failed.
pg_dump: Error message from server: ERROR: unexpe
Chris Purcell wrote:
Hi,
On running pg_dump, I am consistently getting the following errors:
pg_dump: ERROR: unexpected chunk number 2 (expected 0) for toast value
223327
pg_dump: SQL command to dump the contents of table "pagecache" failed:
PQendcopy() failed.
pg_dump: Error message from se
"old image" - does that refer to something like an filesystem level
backup or the restoration of a former pg_dump generated backup ?
The former is generally NOT save (except if you followed the PITR-
advises in the docs or similiar) with a running postmaster ...
Ah. Yes, the former, as we did
Actually, it looks like the backend that handles the connection is the culprit
and not the poastmaster. Sorry for the incorrect info.
- Original Message
From: Shelby Cain <[EMAIL PROTECTED]>
To: Joek Hondius <[EMAIL PROTECTED]>; pgsql-bugs@postgresql.org
Sent: Thursday, September 7, 200
Chris Purcell <[EMAIL PROTECTED]> writes:
> Given that we are where we are, what is the best advice? Can we
> recover the database, given that 99% of the data works? I can happily
> drop the entire contents of the "pagecache" table, as it is
> regenerated on the fly, if that will obviate the
That will get you past the reported problem, but I wonder what other
corruption is lurking ... once you've managed to pg_dump you'd better
inspect the data very carefully.
Would the best advice be to get a pg_dump, then drop the database
entirely and rebuild it?
Cheers,
Chris
-
Chris Purcell <[EMAIL PROTECTED]> writes:
>> That will get you past the reported problem, but I wonder what other
>> corruption is lurking ... once you've managed to pg_dump you'd better
>> inspect the data very carefully.
> Would the best advice be to get a pg_dump, then drop the database
> ent
Would the best advice be to get a pg_dump, then drop the database
entirely and rebuild it?
Definitely. It's entirely possible for pg_dump to dump successfully
from a database that still contains corruption. An example:
broken indexes on user tables. COPY just does a seqscan and never
looks
Chris Purcell <[EMAIL PROTECTED]> writes:
> Would the best advice be to get a pg_dump, then drop the database
> entirely and rebuild it?
>>
>> Definitely. It's entirely possible for pg_dump to dump successfully
>> from a database that still contains corruption. An example:
>> broken indexes on u
See REINDEX. But my point was that there may be undetected
corruption.
If I were you I'd not rely on REINDEX to prevent all problems.
Indeed; REINDEX neither detected nor fixed the corruption.
Thanks for all your help; we'll recreate the database as soon as we can.
Many thanks,
Chris Purcel
10 matches
Mail list logo
