Hi all,
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
Oh, I've forgot to mention that the DB is version 8.0.3 running on
linux.
Cheers,
Csaba.
On Tue, 2005-08-09 at 15:19, Csaba Nagy wrote:
Hi all,
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
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
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
On Tue, Aug 09, 2005 at 04:25:30PM +0200, Csaba Nagy wrote:
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.
The message is in src/backend/postmaster/pgstat.c:
if (!overflow)
{
[snip]
I've executed a select pg_stat_reset(); as superuser, and all went
away except the offending row...
That only resets the I/O counts (and only for one database), not the
backend activity info.
regards, tom lane
This reminds me I've forgot to ask, is there
Csaba Nagy [EMAIL PROTECTED] writes:
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.
This is not totally surprising, since the pgstat
Csaba Nagy [EMAIL PROTECTED] writes:
I've executed a select pg_stat_reset(); as superuser, and all went
away except the offending row...
That only resets the I/O counts (and only for one database), not the
backend activity info.
This reminds me I've forgot to ask, is there any other way of
On 8/9/2005 12:21 PM, Tom Lane wrote:
Csaba Nagy [EMAIL PROTECTED] writes:
I've executed a select pg_stat_reset(); as superuser, and all went
away except the offending row...
That only resets the I/O counts (and only for one database), not the
backend activity info.
This reminds me I've
Jan Wieck [EMAIL PROTECTED] writes:
Jan, any thoughts?
The reset call is supposed to throw away everything. If it leaves crap
behind, I'd call that a bug.
resetcounters only thinks it is supposed to zero the counters for the
current database. That seems considerably different from throw
Jan Wieck wrote:
On 8/9/2005 12:21 PM, Tom Lane wrote:
This reminds me I've forgot to ask, is there any other way of getting
rid of those ghost entries than via big load ?
Not at the moment. It might be worth teaching the pgstats code to
cross-check the activity list every so often, but
11 matches
Mail list logo
