Re: [HACKERS] Status of autovacuum and the sporadic stats failures ?

2007-02-07 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes: > FWIW I'm thinking that the corresponding code for handling the backends' > stats could be simplified, removing the hack that stores it in > TopTransactionContext, and just having a call to the stats flush > function in AbortTransaction and CommitTransact

Re: [HACKERS] Status of autovacuum and the sporadic stats failures ?

2007-02-07 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Beluga just failed: > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=beluga&dt=2007-02-07%2019:30:01 Wow, that is a really interesting failure, because it implies that the stats collector had seen the seqscan report but not the indexscan report:

Re: [HACKERS] Status of autovacuum and the sporadic stats failures ?

2007-02-07 Thread Alvaro Herrera
Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> It'd be interesting to try to gather stats on the length of the delay > >> taken, but I don't see a good way to do that within the current > >> regression-test infrastructure. > > > Have it log something that wil

Re: [HACKERS] Status of autovacuum and the sporadic stats failures ?

2007-02-07 Thread Alvaro Herrera
> Tom Lane wrote: > > None of your use-cases require tracking multiple sets of stats within a > > transaction, so I don't see why bother with that when we can just add a > > "flush the stats" call. FWIW I'm thinking that the corresponding code for handling the backends' stats could be simplified,

Re: [HACKERS] Status of autovacuum and the sporadic stats failures ?

2007-02-07 Thread Alvaro Herrera
Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> We could make it cleaner by inventing a function to clear out the cached > >> statistics within a transaction, perhaps "pg_stat_reset_snaphot()" or > >> some such name. If anyone thinks that that would be of gene

Re: [HACKERS] Status of autovacuum and the sporadic stats failures ?

2007-02-07 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> We could make it cleaner by inventing a function to clear out the cached >> statistics within a transaction, perhaps "pg_stat_reset_snaphot()" or >> some such name. If anyone thinks that that would be of general >> usefulness, I'll se

Re: [HACKERS] Status of autovacuum and the sporadic stats failures ?

2007-02-07 Thread Alvaro Herrera
Tom Lane wrote: > We could make it cleaner by inventing a function to clear out the cached > statistics within a transaction, perhaps "pg_stat_reset_snaphot()" or > some such name. If anyone thinks that that would be of general > usefulness, I'll see about making it happen. During the developmen

Re: [HACKERS] Status of autovacuum and the sporadic stats failures ?

2007-02-07 Thread Tom Lane
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> It'd be interesting to try to gather stats on the length of the delay >> taken, but I don't see a good way to do that within the current >> regression-test infrastructure. > Have it log something that will appear on the postmaster log

Re: [HACKERS] Status of autovacuum and the sporadic stats failures ?

2007-02-06 Thread Tom Lane
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I'm tempted to propose replacing the fixed sleep with a short plpgsql >> function that sleeps for a second, checks to see if the stats have >> changed, repeats if not; giving up only after perhaps 30 seconds. >> >> It'd be interesting

Re: [HACKERS] Status of autovacuum and the sporadic stats failures ?

2007-02-06 Thread Andrew Dunstan
Tom Lane wrote: I'm tempted to propose replacing the fixed sleep with a short plpgsql function that sleeps for a second, checks to see if the stats have changed, repeats if not; giving up only after perhaps 30 seconds. It'd be interesting to try to gather stats on the length of the delay taken,

Re: [HACKERS] Status of autovacuum and the sporadic stats failures ?

2007-02-06 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Also note this message: >> If this theory is correct, then we can improve the reliability of the >> stats test a good deal if we put a sleep() at the *start* of the test, >> to let any old backends get out of the way. It seems worth a try >> anyway. I'

Re: [HACKERS] Status of autovacuum and the sporadic stats failures ?

2007-02-06 Thread Stefan Kaltenbrunner
Alvaro Herrera wrote: > Alvaro Herrera wrote: > >> Setting the cost_delay sounds a reasonable thing to do anyway, and in >> fact I already proposed it and nobody objected (AFAIR). Now we only >> have to agree on a reasonable value. > > Also note this message: > > Date: Sat, 27 Jan 2007 21:51:40

Re: [HACKERS] Status of autovacuum and the sporadic stats failures ?

2007-02-06 Thread Stefan Kaltenbrunner
Alvaro Herrera wrote: > Stefan Kaltenbrunner wrote: >> I'm still getting random failures from some of my buildfarm members >> which is starting to get a bit irritating and annoying :-( >> >> some recent failures: >> >> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=zebra&dt=2007-02-06%2015:

Re: [HACKERS] Status of autovacuum and the sporadic stats failures ?

2007-02-06 Thread Alvaro Herrera
Alvaro Herrera wrote: > Setting the cost_delay sounds a reasonable thing to do anyway, and in > fact I already proposed it and nobody objected (AFAIR). Now we only > have to agree on a reasonable value. Also note this message: Date: Sat, 27 Jan 2007 21:51:40 -0500 Message-ID: <[EMAIL PROTECTED]

Re: [HACKERS] Status of autovacuum and the sporadic stats failures ?

2007-02-06 Thread Alvaro Herrera
Stefan Kaltenbrunner wrote: > I'm still getting random failures from some of my buildfarm members > which is starting to get a bit irritating and annoying :-( > > some recent failures: > > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=zebra&dt=2007-02-06%2015:25:04 > http://buildfarm.pos

[HACKERS] Status of autovacuum and the sporadic stats failures ?

2007-02-06 Thread Stefan Kaltenbrunner
I'm still getting random failures from some of my buildfarm members which is starting to get a bit irritating and annoying :-( some recent failures: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=zebra&dt=2007-02-06%2015:25:04 http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=clownfi