Thank you for a reply, everybody.
> On Mon, Jun 14, 2010 at 11:28 AM, Shinji Nakajima <sina...@jops.co.jp> > wrote: > > PostgreSQL version: 8.3.8 > > Description: missing chunk number 0 for toast value XXXXX in > > pg_toast_XXXXX > > > > I delete a record, and the system restores, but prime cause is unknown. > > Will this be a bug of the databases? > > Probably. Or possibly bad hardware. Assuming you didn't manually go in > and delete that record from the toast table, which would be a strange > thing to do. > The table restored. However, there were tables when I checked the other tables. Because primary key repeated in the same table, similar error message was displayed when I did select entirely. > The problem is it could have happened a long time ago and you just > discovered it now. Have you had any other significant events on this > machine? Any system crashes or power failures? Any drive crashes or > signs of bad memory? > postgres is duplicated. Red Hat Cluster Suite watches a process of each service. PGDATA shares it in strage. There is the thing that a wait server started. A cluster began the change disposal of servers. Because A cluster judged a state of postgres to be a stop. I do not understand why duplex system to refer to same PGDATA was able to start. I was able to surely carry out SQL by a psql command in duplex system. I did not output log in those days. > In the postgres logs are there any instances of unusual error messages > or warnings? > -- > greg It continues, and an error occurs. "could not read block 17 of relation 1663/16872/2840: read only 0 of 8192 bytes" A data file seems to be broken... Two postgres that PGDATA was shared will have started why if it was thought that it was caused by double start. Is there such a precedent? Does a data file lead to the cause that failed? Regards, Nakajima -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
