Re: Still big problems with pg_dump!
От | Wim |
---|---|
Тема | Re: Still big problems with pg_dump! |
Дата | |
Msg-id | 3D873B69.1000105@belbone.be обсуждение исходный текст |
Ответ на | Still big problems with pg_dump! (Wim <wdh@belbone.be>) |
Ответы |
Re: Still big problems with pg_dump!
|
Список | pgsql-general |
Andrew Sullivan wrote: >-hackers removed. > >On Tue, Sep 17, 2002 at 10:11:41AM +0200, Wim wrote: > > > >>ERROR: AllocSetFree: cannot find block containing chunk 4c5ad0 >> >> > >This is definitely some sort of disk problem. Either you've written >bad data to the disk in some way, or else the disk is corrupted or >damaged. > >If it is a hardware problem, the obvious suspects are memory (I'd >discount this idea unless everything else doesn't check out), a disk >failure, or a controller failure. > >It could be OS related as well. Several of the 2.4 Linux kernel >series, for instance, had roblems with massive filesystem corruption. > > Postgres is running on solaris 8... It is the same database as previous time that has the problem, but not the same table. I think it's an error is the system tables. > > >>Some people suggest a drive failure, but I checked that and found no >>problems... >> >> > >How did you check? > > with fsck. > > >>I must say that one of the table contains more than 3.000.000 rows, >>another more than 1.400.000... >> >> > >When is your most recent backup? If you can't pg_dump, you will be >needing that backup. > > Have backup... I can still SQL COPY to a text file, so that's no problem so far. > > >>I must say that I had this problem a few months before, I got some help >>then, but that couldn't solve my problem, >>I recreated the database from scratch and copied the data, to fix thing >>quickly. Thing went well for about two months :-( >> >> > >So you re-installed the data set on a machine that had somehow >failed, you don't know why, and hoped that the problem would >solve itself? Uh, that wasn't a good idea. In the future, if you >have a problem which people suggest might be, for instance, a bad >disk, it'd be a _very good_ idea to figure out precisely what the >problem is before relying on the identical hardware again. > >A > > > I know, I don't have much spare hardware, and the database had to work quickly, it was the only solution then. Checked the disk, reinstalled the OS and still waiting for a CPU and memory upgrade.
В списке pgsql-general по дате отправления: