[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(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org