postmaster locks up in 7.1b3

paul vixie (paul(at)vix(dot)com) reports a bug with a severity of 2
The lower the number the more severe it is.

Short Description
postmaster locks up in 7.1b3

Long Description
this morning at 1:00AM our nightly "vacuum analyze;" ran from cron
and immediately went idle. both the psql process and the resulting
child of the postmaster were using no CPU time. all other subsequent
accessors whether psql or DBI also hung. i was not able to determine
whether they were locking up on opening the session or on the first
command. by the time i came on the scene there were dozens of hung
children of the postmaster and also dozens of hung psql/DBI processes.

what fixed it was killing off a bunch of remote psql and DBI clients.
nothing was killed on the postmaster host. the result was that all
hung psql/DBI processes completed normally, all hung children of the
postmaster seemed to complete normally, and the "vacuum analyze"
started actually chewing up CPU and I/O, completing normally about
five minutes later (which is the usual total run time.)

this is on a dual-CPU freebsd-4.1-release host, in case serialization
of access to the shared memory (if any) between the postmaster and
its various children is an issue. what it felt like was a deadlock
that was broken when the remote psql/DBI clients were killed -- this
would have resulted in a select() wakeup on at least readfds and
exceptfds and perhaps writefds as well.

i am upgrading to 7.1.2 on the postmaster, with a full pg_dumpall and
restore, to rule out "old bugs" (possible?) and on-disk corruption
(possible, too, i guess?) and if it reoccurs i will get stack traces
and fstat's and whatnot. so this is really just a heads-up for now.

Sample Code

No file was uploaded with this report