Also you should check for any CPU malfunction, overheating, etc..
and for motherboard problems as well, power supply, etc...
Anyway, your problem is not postgresql (postgresql does not delete its own
files).
Your problem is below your OS and everything that comes underneath.
What do the linux log
Whoever did the memory installation, should also have taken care of checking
it's working ok.
A good idea is to use ECC memory.
Does fsck on the remote system run with reporting problems as well?? (it might
report problems such as incorrect block counts, missing inodes etc...)
Also check for dis
Hi Achilleas,
Thanks for your quick response.
We do have backups and a couple of spare servers running in parallel so
we're safe in that sense. Thanks for your advice anyway.
To run *memtest86 *we have to go to the datacenter and that will take us a
few days. Is there anything we can do remotely?
Stop using the system immediately, since many things inserted to the DB might
simply be garbage.
Inspect your memory with memtest86.
I would even suggest moving to a new HW if available, and start working into
two parallel directions:
a) try to bring your DB into a sane state
b) try to fix your
Hi all,
We've been using postgres for 9 years without a problem until now! Two
problems in a very short time!
The first one is described in
http://postgresql.1045698.n5.nabble.com/Autovacuum-seems-to-block-database-WARNING-worker-took-too-long-to-start-td3264261.html
This is another one (not relat
