Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> maybe not only windows boxes:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=zebra&dt=2007-01-20%2015:25:05
Wow, I just saw the stats failure on my own machine, for the first time
ever. Conclusions:
1. Enabling autovac has definitely ra
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> 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.
> maybe not only win
Alvaro Herrera wrote:
> 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 t
Tom Lane wrote:
Perhaps we could extend pg_regress to allow "--max-connections=auto"
which would instruct it to set its connection limit to the server's
actual max_connections minus superuser reserved slots (and probably
minus a couple more to allow for backend shutdown time etc). Then the
buil
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Maybe what we really ought to do is pick an internal max_connections
> value that exceeds what the max_connections GUC parameter say, adjusting
> per autovacuum configuration.
That's just cosmetic; it doesn't address the real issue, which is that
if SHM
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I noticed today on my own machine several strange pauses while running
>> the serial regression tests ---
> Do those explain what you are seeing?
No, those are expected. I'm having a hard time reproducing the behavior
right now, but
Stefan Kaltenbrunner wrote:
> Alvaro Herrera wrote:
> > All our Windows buildfarm machines are failing. AFAICT, the first
> > failure was on Yak,
> > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=yak&dt=2007-01-16%2021:55:20
> >
> > and the last successful run just before that seems to
Stefan Kaltenbrunner wrote:
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
yeah - looks like it's the autovacuum change - snake is now passing the
numeric-test but still fails the stats one ...
Interesting -- both yak and snake are failing in a
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> Stefan Kaltenbrunner wrote:
>
>>> yeah - looks like it's the autovacuum change - snake is now passing the
>>> numeric-test but still fails the stats one ...
>> Interesting -- both yak and snake are failing in a very similar way.
>> I'll investigate
Tom Lane wrote:
> 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 su
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
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
Alvaro Herrera wrote:
> Stefan Kaltenbrunner wrote:
> > yeah - looks like it's the autovacuum change - snake is now passing the
> > numeric-test but still fails the stats one ...
>
> Interesting -- both yak and snake are failing in a very similar way.
> I'll investigate it tomorrow if no one beat
13 matches
Mail list logo
