On Apr 4, 2006, at 1:29 AM, Tom Lane wrote:
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
It is probably related to something we've been seeing in the
PostgreSQL
logs on the Windows servers:
[2006-04-03 08:28:25.990 ] 2072 FATAL: could not read from
statistics
collector pipe: No error
[20
On Apr 3, 2006, at 12:52 PM, Tom Lane wrote:
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
Is there any way to tweak this in favor of more accurate information,
even if has a performance cost? We're finding that during normal
operations we're not seeing most connections added to the
pg_stat_act
-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 04, 2006 3:52 PM
To: Lane Van Ingen
Cc: Kevin Grittner; Jerry Sievers; pgsql-admin@postgresql.org; Peter
Brant
Subject: Re: [ADMIN] pg_stat_activity showing non-existent processes
"Lane Van Ingen" <[EMAIL PROTECTED]>
IL PROTECTED] Behalf Of Tom Lane
Sent: Tuesday, April 04, 2006 1:29 AM
To: Kevin Grittner
Cc: Jerry Sievers; pgsql-admin@postgresql.org; Peter Brant
Subject: Re: [ADMIN] pg_stat_activity showing non-existent processes
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> It is probably related to
"Lane Van Ingen" <[EMAIL PROTECTED]> writes:
> Don't understand the 'target machine' message, either; in this case, we are
> running the application and the database server on the same box.
> 2006-04-04 03:12:05 FATAL: could not read from statistics collector pipe:
> No error 2006-04-04 03:12:06
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> It is probably related to something we've been seeing in the PostgreSQL
> logs on the Windows servers:
> [2006-04-03 08:28:25.990 ] 2072 FATAL: could not read from statistics
> collector pipe: No error
> [2006-04-03 08:28:26.068 ] 2012 LOG: statisti
>>> On Mon, Apr 3, 2006 at 11:52 am, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> Is there any way to tweak this in favor of more accurate
information,
>> even if has a performance cost? We're finding that during normal
>> o
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Is there any way to tweak this in favor of more accurate information,
> even if has a performance cost? We're finding that during normal
> operations we're not seeing most connections added to the
> pg_stat_activity table. We would like to be able to
>>> On Sat, Mar 25, 2006 at 8:40 pm, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Jerry Sievers <[EMAIL PROTECTED]> writes:
>> At any rate; I'm wondering what possible causes might be
responsible
>> for pg_stat_activity's underlying functions to lose track of the
valid
>>
Tom Lane <[EMAIL PROTECTED]> writes:
> Jerry Sievers <[EMAIL PROTECTED]> writes:
> > At any rate; I'm wondering what possible causes might be responsible
> > for pg_stat_activity's underlying functions to lose track of the valid
> > process list?
>
> It sounds like the stats collector missed a fe
Jerry Sievers <[EMAIL PROTECTED]> writes:
> At any rate; I'm wondering what possible causes might be responsible
> for pg_stat_activity's underlying functions to lose track of the valid
> process list?
It sounds like the stats collector missed a few "backend quit"
messages. This isn't real surpri
Hello; Briefly, we've been fighting an "old idle transaction" problem
on our Pg 8.0.3 Solaris 2.9 production system for a long time. This
is due to some quirks in our app server code (to be fixed ASAP
).
Hourly we run a script that SIGTERMs all backends reported as being in
idle transaction state
12 matches
Mail list logo
