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 th
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 "thr
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'v
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
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 pg
[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, i
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)
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 "", still running after 25 minutes, and the associated
process is gone,
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
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
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 fi
11 matches
Mail list logo