Michael,
I've read the message you referred, and it's probably what happens.
In fact the original row I've complained about is gone, and I have now
10 other dead processes listed in pg_stat_activity... one of the queries
is a "<BIND>", still running after 25 minutes, and the associated
process is gone, so it's clearly an inconsistent state of the stats
collector. I wonder if there's a way to fix that without too much
affecting performance ?
The logs don't show the "statistics buffer is full" message as suggested
by Tom, but ITOH "log_min_messages = info", and that message might be a
debug level one.
In any case it seems my system can readily reproduce the issue whenever
I place a bigger load on it...
Cheers,
Csaba.
On Tue, 2005-08-09 at 15:51, Michael Fuhr wrote:
> On Tue, Aug 09, 2005 at 03:19:46PM +0200, Csaba Nagy wrote:
> > I have a postgres system where we just migrated a fairly big data set.
> > The application accessing it is a cluster of servers which do burst-like
> > processing, i.e. when they have some work to do, it will be distributed
> > in the cluster and the data base will be under fairly high load.
> > On our first test run everything went fine, the only strange thing is a
> > row in the pg_stat_activity, which has a row about a query which is long
> > gone, the process pointed by the procpid field is not existing.
>
> I ran across this situation a while ago, where high load caused
> pg_stat_activity to have stale entries. Tom Lane wondered if the
> stats subsystem was under a high enough load that it was dropping
> messages, as it's designed to do.
>
> http://archives.postgresql.org/pgsql-bugs/2004-10/msg00163.php
