> As far as Postgres is concerned, there's no deadlock here, only a slow client
that could be true if we used explicit locks. all our accesses are of the
form "learn everything you need to know to do the transaction, then open the
database, do it, and close". there are some really long SELECT's
Paul A Vixie <[EMAIL PROTECTED]> writes:
>> As far as Postgres is concerned, there's no deadlock here, only a slow client
> that could be true if we used explicit locks. all our accesses are of the
> form "learn everything you need to know to do the transaction, then open the
> database, do it,
[EMAIL PROTECTED] writes:
> 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 a
paul vixie ([EMAIL PROTECTED]) 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 t
