Michael Fuhr <mike (AT) fuhr (DOT) org> writes:
Define "old"? There's a built-in delay of up to half a second (if
memory serves) in the statistics views.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

On Sun, Oct 17, 2004 at 12:01:45AM -0400, Tom Lane wrote:
Fourteen minutes and counting.

I just noticed the problem this evening so I don't know how long
the stale connections remain in the view. During my testing I was
restarting the backend frequently to start each run afresh; I'll
leave the current situation alone for a while and see what happens.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

On Sat, Oct 16, 2004 at 10:30:12PM -0600, Michael Fuhr wrote:
Two hours and counting. I've also reproduced the problem using
pgbench against 8.0.0beta3 on FreeBSD 4.10-STABLE.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Michael Fuhr <mike (AT) fuhr (DOT) org> writes:
The other likely theory is that the stats subsystem is under
sufficiently heavy load that it drops a certain proportion of stats
messages (as it is designed to do, rather than causing foreground
activity to block). If it were to drop a backend-termination message
then of course that connection would remain depicted in pg_stat_activity
until the stats collector figures out that the backend is gone. Which
IIRC would normally happen when some new backend re-uses its BackendId
slot.

You could check for log messages "statistics buffer is full" as a
partial check of this theory. This is only partial because it isn't
a direct test of whether messages are being dropped.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html