[6.5.3] first spinlock problem I've ever noticed ...

Jsut doing a vacuum of my database, and foundsomething that I consider to
be "odd" ... while vacuuming one of the tables, doign a ps shows:

64185  p8  S      0:00.10 /home/database/v6.5.3/bin/postgres pgsql 216.126.84.1 ipmeter VACUUM
64202  p8  S      0:00.04 /home/database/v6.5.3/bin/postgres jeff 216.126.84.1 jeff startup
64203  p8  S      0:00.03 /home/database/v6.5.3/bin/postgres hordemgr 216.126.84.1 horde startup
64206  p8  S      0:00.04 /home/database/v6.5.3/bin/postgres jeff 216.126.84.1 jeff startup
64223  p8  S      0:00.02 /home/database/v6.5.3/bin/postgres pgsql 216.126.84.1 banner_ad startup
64235  p8  S      0:00.01 /home/database/v6.5.3/bin/postgres pgsql 216.126.84.1 banner_ad startup
64236  p8  S      0:00.01 /home/database/v6.5.3/bin/postgres hordemgr 216.126.84.1 horde startup
64238  p8  S      0:00.01 /home/database/v6.5.3/bin/postgres pgsql 216.126.84.1 banner_ad startup
64240  p8  S      0:00.01 /home/database/v6.5.3/bin/postgres jeff 216.126.84.1 jeff startup
64255  p8  S      0:00.00 /home/database/v6.5.3/bin/postgres jeff 216.126.84.1 jeff startup

ipmeter was being vacuum'd, but the rest were "hanging"?

Eventually, I got a:

FATAL: s_lock(5004c3d4) at bufmgr.c:665, stuck spinlock. Aborting.

message on the vacuum and then everthing went back to normal ...

I'm tempted to upgrade to v7.0 and see how she goes, but am wondering if
there is something that I should be looking at *beforE* I do that?


Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org