On Tue, 17 Sep 2002, Wim wrote:
> >
> >It is somewhat worrying that the same problem has reoccured. You checked your
> >hard disk but what about memory?
> >
> Checked with vmstat:
> kthr memory page disk faults cpu
> r b w swap free re mf pi po fr de sr m1 m1 m1 m2 in sy cs us
> sy id
Not Intel architecture then. Is there a way of testing the memory modules, like
memtest86, although that sort of thing is obviously a very distruptive task on
a production system.
> >
> >pg_dumpall fails but what about just pg_dump on the individual DBs?
> >
> pg_dump fails on one database... other DB's are dumped...
Same DB as the previous failure?
> >
> >Is it a production system? If it continues to cause problems what about
> >considering bringing someone in to investigate?
> >
> >
> Indeed, it's a production system.
> What do you mean by bringing someone in to investigate? Someone from
> Postgres?
Yes, that's what I was thinking you might need. Someone with expert knowledge
poking around the data and system.
>
> PS: I have some debugging output...
I probably wouldn't know what to make of it.
Maybe someone will have better suggestions but all I can suggest for now is to
see if pg_dump -s can dump the schema and also to run a parallel installation,
after solving the problem of course, and waiting to see if the problem triggers
on both systems at the same point.
If pg_dump -s works and selecting from all the tables in the 'broken' DB works
then there must be some sort of problem in the combination of schema and data.
--
Nigel J. Andrews
