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                      
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to