Обсуждение: URGENT! pg_dump doesn't work!
Hello guys,
I have a problem with my postgres 7.2.1 database.
I can't perform a pg_dump one my database...
The message I get back is:
pg_dump: query to obtain list of tables failed: server closed the
connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
pg_dump failed on belbonedb_v2, exiting
Whe I connect to the database and do:
belbonedb_v2=# \dt networks
I get:
ERROR: AllocSetFree: cannot find block containing chunk 4aee70
Can I fix this error?
Thanx!
Wim
On Mon, 22 Jul 2002, Wim wrote: > Hello guys, > > I have a problem with my postgres 7.2.1 database. > I can't perform a pg_dump one my database... > The message I get back is: > > pg_dump: query to obtain list of tables failed: server closed the > connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > pg_dump failed on belbonedb_v2, exiting > > Whe I connect to the database and do: > > belbonedb_v2=# \dt networks > > I get: > > ERROR: AllocSetFree: cannot find block containing chunk 4aee70 > > > Can I fix this error? Is this perhaps another of those hardware errors that seem to be turning up at the moment? So Wim, did you have improper shutdowns? Are you confident in your memory and hard disk(s)? -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants
Nigel J. Andrews wrote: >On Mon, 22 Jul 2002, Wim wrote: > >>Hello guys, >> >>I have a problem with my postgres 7.2.1 database. >>I can't perform a pg_dump one my database... >>The message I get back is: >> >>pg_dump: query to obtain list of tables failed: server closed the >>connection unexpectedly >> This probably means the server terminated abnormally >> before or while processing the request. >>pg_dump failed on belbonedb_v2, exiting >> >>Whe I connect to the database and do: >> >>belbonedb_v2=# \dt networks >> >>I get: >> >>ERROR: AllocSetFree: cannot find block containing chunk 4aee70 >> >> >>Can I fix this error? >> > > >Is this perhaps another of those hardware errors that seem to be turning up at >the moment? > >So Wim, did you have improper shutdowns? Are you confident in your memory and >hard disk(s)? > > The database is never killed with the -9 and I have no problems with my hard disks or memory... Is it a bug that can be fixed? I can create a DB with the same tables and do a 'copy from/to' to transfer the data. 'Cause it is a large DB (tables with more that 1 million rows) , I would do this if I have no other option left... Thanx! Wim
On Mon, 22 Jul 2002, Wim wrote: > Nigel J. Andrews wrote: > > >On Mon, 22 Jul 2002, Wim wrote: > > > >>Hello guys, > >> > >>I have a problem with my postgres 7.2.1 database. > >>I can't perform a pg_dump one my database... > >>The message I get back is: > >> > >>pg_dump: query to obtain list of tables failed: server closed the > >>connection unexpectedly > >> This probably means the server terminated abnormally > >> before or while processing the request. > >>pg_dump failed on belbonedb_v2, exiting > >> > >>Whe I connect to the database and do: > >> > >>belbonedb_v2=# \dt networks > >> > >>I get: > >> > >>ERROR: AllocSetFree: cannot find block containing chunk 4aee70 > >> > >> > >>Can I fix this error? > >> > > > > > >Is this perhaps another of those hardware errors that seem to be turning up at > >the moment? > > > >So Wim, did you have improper shutdowns? Are you confident in your memory and > >hard disk(s)? > > > > > The database is never killed with the -9 and I have no problems with my > hard disks or memory... > Is it a bug that can be fixed? I can create a DB with the same tables > and do a 'copy from/to' to transfer the data. > 'Cause it is a large DB (tables with more that 1 million rows) , I would > do this if I have no other option left... When you say you can copy from the tables you have tried this and succeeded I presume. Have you checked the server log to see that it is giving the same message as you see in psql? What about that value to give in the error message (4aee70), is it always the same value? Does that look like a reasonable address with in a programs data space on your system? Having looked at the code it seems that somewhere something is trying to free a memory chunk that is bigger than the chunk limit (ALLOC_CHUNK_LIMIT), 8Kb I believe from the comments, that has either already been freed or has not been allocated. Therefore it's sounding a little like some pointer is being trashed somewhere. If you could obtain a stack trace from the backend it might be useful. Look in the directories in your data directory for core files. You may need to enable core file dumping with something like ulimit -c unlimited before starting your server. Alternately, start psql and use gdb to attach to the backend process serving it and obtain the back trace when it faults. -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants
Wim <wdh@belbone.be> writes:
> I have a problem with my postgres 7.2.1 database.
> I can't perform a pg_dump one my database...
> The message I get back is:
Odd. I am thinking this might be a corrupted-data problem.
If you are lucky, the corruption is in an index, and you can fix it
by rebuilding the system indexes. Read the REINDEX reference page
(carefully, it's a convoluted procedure)
regards, tom lane
On Mon, 22 Jul 2002, Tom Lane wrote: > Wim <wdh@belbone.be> writes: > > I have a problem with my postgres 7.2.1 database. > > I can't perform a pg_dump one my database... > > The message I get back is: > > Odd. I am thinking this might be a corrupted-data problem. > > If you are lucky, the corruption is in an index, and you can fix it > by rebuilding the system indexes. Read the REINDEX reference page > (carefully, it's a convoluted procedure) Tom, That's why I went down the hardware question. Given the error reported by Wim though seems to be a memory allocation, actually freeing, fault would data corruption in any persistent storage object be suspect? I suppose it worth checking that the error persists across a backend restart. Wim? -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants
"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> That's why I went down the hardware question. Given the error reported by Wim
> though seems to be a memory allocation, actually freeing, fault would data
> corruption in any persistent storage object be suspect?
I am thinking a corrupted length word in a varlena data item (text,
varchar, array, etc) might possibly lead to that sort of error.
It's just an educated guess though.
regards, tom lane