Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Now, if some Windows-enabled person could step forward so that we can > > suggest some tests to run, that would be great. Perhaps the solution to > > the problem is to relax the conditions a little, so that two scans are > > accepted on that table instead of only one; but it would be good to > > confirm whether the stat system is really working and it's really still > > counting stuff as it's supposed to do. > > No, you misread it: the check is for at least one new event, not exactly > one.
Doh :-( > We've been seeing this intermittently for a long time, but it sure seems > that autovac has raised the probability greatly. That's pretty odd. > If it's a timing thing, why are all and only the Windows machines > affected? Could it be that autovac is sucking all the spare cycles > and keeping the stats collector from running? Hmm, that could explain it, but it's strange that only Windows machines are affected. Maybe it's a scheduler issue, and the Unix machines are able to let pgstat do some work but Windows are not. > (Does autovac use vacuum_cost_delay by default? It probably should if > not.) The default autovacuum_vacuum_cost_delay is -1, which means "use the system default", which in turn is 0. So it's off by default. > I noticed today on my own machine several strange pauses while running > the serial regression tests --- the machine didn't seem to be hitting > the disk nor sucking lots of CPU, it just sat there for several seconds > and then picked up again. I wonder if that's related. It sure seems it > must be due to autovac being on now. Hmm, strange; I ran the tests several times today testing Magnus changes, and I didn't notice any pause. It was mostly the parallel tests though; I'll try serial. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
