Hi all, Attached are two patches which in combination make pg_stat_activity work reliably for us on Windows.
The mysterious socket error turned out to be WSAEWOULDBLOCK. Per http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/windows_sockets_error_codes_2.asp , it seems the thing to do is loop and try again. pipe.patch does that. pgstat.patch removes the delayed destroy code for backends, databases, and tables. Database and table entries are cleaned up immediately upon receipt of the appropriate message. Both patches were necessary to make pg_stat_activity work reliably. With no changes, with a connection pool size of 31, under load, we'd typically see < 5 rows in pg_stat_activity. With pgstat.patch applied, the number of rows would typically be between 15 and 20. With pipe.patch also applied, the number of rows in pg_stat_activity was accurate. The test server withstood an approximately four hour test stress test which replays captured Web traffic, but at full blast. The machine was completely swamped, but there were no socket errors over the test run (compared to a frequency of once every couple minutes before). The one remaining problem is that there seems to be a race condition when installing the temporary stats file on Windows. As we were monitoring pg_stat_activity during the test run, occasionally we'd get a response with zero rows. This may not be much of a problem during normal conditions (the server was completely overloaded and we were banging away with "Up Arrow", "Enter" watching pg_stat_activity). What's the best way to do an atomic rename on Windows? Alternatively, would it make sense to sleep and try again (up to some limit) when trying to open the stats file on Windows? Pete
pipe.patch
Description: Binary data
pgstat.patch
Description: Binary data
---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
