Re: "could not reattach to shared memory" captured in buildfarm - Mailing list pgsql-hackers

From Dave Page
Subject Re: "could not reattach to shared memory" captured in buildfarm
Date
Msg-id 937d27e10905021001k43c524c1wfc476934626aca5f@mail.gmail.com
Whole thread Raw
In response to "could not reattach to shared memory" captured in buildfarm  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, May 2, 2009 at 4:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> I assume vaquita's configuration hasn't changed recently (Dave?)
> so this seems to put the lie to the theory we've taken refuge in
> that it's caused by bad antivirus software.  I don't see that it
> gets us any closer to a solution though.

Well, theres a bit of a story there. Vaquita and Baiji are both the
same Vista machine running on VMware Server. About a month back, for
what seemed like no reason, the guest VM started running at much
higher speed than it should - animated cursors started running at
double speed, double-clicking become impossible and the clock started
gaining significant amounts of time - to the expent that buildfarm
runs were rejected by the server because the finish time was in the
future.

I believe I finally fixed this on Friday - from what I can tell, it
looks like the Java self-update applet was causing the clock rate on
the host to be raised to 1000/1024Hz (this can be done using the
multimedia API). This in turn was apparently upsetting VMware. Anyway,
long story short, removed the JVM from the host and everything appears
to have returned to normal. Nothing has changed in the config of the
VM itself, though a couple of minor tweaks were made to the VMware
configuration - but they were clock-related.

--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Updated Korean character set mappings
Next
From: Andrew Dunstan
Date:
Subject: windows doesn't notice backend death