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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
