Thank you for a reply, everybody.
> On Mon, Jun 14, 2010 at 11:28 AM, Shinji Nakajima <sinakaj@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 iso-8859-1.
> > 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
