Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id BDA5011F7E64 for ; Wed, 20 Jun 2012 02:54:19 -0300 (ADT) Received: from adsltrust.ath.forthnet.gr ([194.219.204.174] helo=smadev.internal.net) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1ShDrt-0003up-2o for pgsql-sql@postgresql.org; Wed, 20 Jun 2012 05:54:18 +0000 Received: from smadev.internal.net (localhost [127.0.0.1]) by smadev.internal.net (8.14.5/8.14.5) with ESMTP id q5K5s1dO090592 for ; Wed, 20 Jun 2012 08:54:01 +0300 (EEST) (envelope-from achill@matrix.gatewaynet.com) Received: (from achill@localhost) by smadev.internal.net (8.14.5/8.14.5/Submit) id q5K5s1GF090591 for pgsql-sql@postgresql.org; Wed, 20 Jun 2012 08:54:01 +0300 (EEST) (envelope-from achill@matrix.gatewaynet.com) X-Authentication-Warning: smadev.internal.net: achill set sender to achill@matrix.gatewaynet.com using -f From: Achilleas Mantzios Organization: Dynacom Tankers Mgmt To: pgsql-sql@postgresql.org Subject: Re: Insane behaviour in 8.3.3 Date: Wed, 20 Jun 2012 08:54:01 +0300 User-Agent: KMail/1.13.7 (FreeBSD/8.3-RELEASE; KDE/4.7.3; amd64; ; ) References: <201206141139.35601.achill@matrix.gatewaynet.com> <201206191217.49743.achill@matrix.gatewaynet.com> <4FE14CA9.8090000@ringerc.id.au> In-Reply-To: <4FE14CA9.8090000@ringerc.id.au> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201206200854.01778.achill@matrix.gatewaynet.com> X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201206/57 X-Sequence-Number: 36711 On =CE=A4=CE=B5=CF=84 20 =CE=99=CE=BF=CF=85=CE=BD 2012 07:08:09 Craig Ringe= r wrote: > On 06/19/2012 05:17 PM, Achilleas Mantzios wrote: > > We had another corruption incident on the very same machine, this time = in > > the jboss subsystem (a "jar cvf" produced corrupted .jar). IMHO this > > means faulty RAM/disk. > > If that is true, then i guess HW sanity checks are even more important > > than SW upgrades. >=20 > ... and a lot more difficult :S >=20 > Log monitoring is often the most imporant part - monitoring for NMIs and > other hardware notifications, checking the kernel log for odd issues or > reports of unexpected segfaults from userspace programs, etc. >=20 That's right, we have written a whole framework for this, but there are alw= ays cases which escape our attention. > -- > Craig Ringer =2D Achilleas Mantzios IT DEPT