Does anyone out there have a Microsoft installation, know how to get the dump(s) desired to diagnose the problems below, know where dumps end up being placed, and know how to interpret dumps? I am willing to try to help solve these problems, but I need some help ... -----Original Message----- From: Tom Lane [mailto:tgl@xxxxxxxxxxxxx] Sent: Tuesday, April 04, 2006 3:52 PM To: Lane Van Ingen Cc: Kevin Grittner; Jerry Sievers; pgsql-admin@xxxxxxxxxxxxxx; Peter Brant Subject: Re: [ADMIN] pg_stat_activity showing non-existent processes "Lane Van Ingen" <lvaningen@xxxxxxxxx> 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 FATAL: could not write to statistics collector > pipe: No connection could be made because the target machine actively > refused it. I think that's Microsoftese for ECONNRESET, ie, the kernel bounced a packet for lack of any listening process to deliver it to. The real question is what's causing the collector to fail (the "could not read"). While it'd be easy to make it retry read attempts, the reason it considers that FATAL is that it really should never happen. I'd like to find out exactly what's happening before we try to fix it. As Kevin mentioned, adding some more debug printout would be helpful. regards, tom lane -----Original Message----- From: pgsql-admin-owner@xxxxxxxxxxxxxx [mailto:pgsql-admin-owner@xxxxxxxxxxxxxx]On Behalf Of Lane Van Ingen Sent: Tuesday, April 04, 2006 3:40 PM To: Tom Lane; Kevin Grittner Cc: Jerry Sievers; pgsql-admin@xxxxxxxxxxxxxx; Peter Brant Subject: Re: [ADMIN] pg_stat_activity showing non-existent processes Perhaps I might be able to help you track this problem down, but I could use some help. The limited amount of discussion on this I Googled up didn't help. We have never seen these messages before; we are assuming that their appearance now (we have been running OK since last August) is related to two recent changes we made to our Windows 2003 Server (SvcPk 1), PostgreSQL 8.0.4 installation: (1) started capturing statistics with the following config parms; all other parms were installation defaults: debug_pretty_print "on" log_min_duration_statement "60" log_min_error_statement "debug1" log_statement "ddl" log_truncate_on_rotation "on" stats_block_level "on" stats_command_string "on" stats_reset_on_server_start "on" stats_row_level "on" stats_start_collector "on" (2) added additional application workload to this server 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 FATAL: could not write to statistics collector pipe: No connection could be made because the target machine actively refused it. 2006-04-04 04:16:58 FATAL: could not read from statistics collector pipe: No error 2006-04-04 04:16:58 FATAL: could not write to statistics collector pipe: No connection could be made because the target machine actively refused it. 2006-04-04 05:47:26 FATAL: could not read from statistics collector pipe: No error 2006-04-04 05:47:27 LOG: statistics collector process (PID 1776) was terminated by signal 1 -----Original Message----- From: pgsql-admin-owner@xxxxxxxxxxxxxx [mailto:pgsql-admin-owner@xxxxxxxxxxxxxx]On Behalf Of Tom Lane Sent: Tuesday, April 04, 2006 1:29 AM To: Kevin Grittner Cc: Jerry Sievers; pgsql-admin@xxxxxxxxxxxxxx; Peter Brant Subject: Re: [ADMIN] pg_stat_activity showing non-existent processes "Kevin Grittner" <Kevin.Grittner@xxxxxxxxxxxx> 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: statistics collector process (PID > 3268) was terminated by signal 1 We've heard reports of instability in the stats collector on Windows before, though I'm not sure if this is exactly the symptom --- check the list archives. Nobody's been able to track it down yet. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
