Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> 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.