On Thu, Oct 14, 2010 at 1:35 AM, Robert Collins <[email protected]> wrote: > I just had a catchup with Stuart about this specific aspect of the > change to pg 8.4. > > The current status is: > - many queries are faster > - some queries have regressed massively on staging and on prod > - some queries have regressed only on prod > > As a result, Stuarts recommending that we get a fresh OOPS for any > timeout bugs filed before we were completely on pg 8.4 - some older > bugs may be fixed now by ppostgresql improvements. > > He is currently trying to identify why some things are fast on staging > and slow on production - I'm going to file a bug in a minute for this, > because if staging is faster than prod at (well anything) it stops > being a good predictor of production performance, and we need that > predictive ability to avoid panics. > > I'm going to add a tag 'pg83' to all the existing timeout bugs; if > you're looking at fixing a timeout bug with that tag, please find a > fresh OOPS for it and remove the tag. If you can't find an OOPS, and > the urls that were slow are consistently fast, I recommend you > consider closing the bug (with a note that it may need to be > reopened). > > That said, the OOPS system is currently a little sick - its not > finding OOPS from lpnet, and Ursula couldn't see why; hopefully Diogo > can look at it in 7-8 hours from now.
I disabled the script which loads oops reports into the oops database while investigating bug https://bugs.edge.launchpad.net/oops-tools/+bug/660218 It's now re-enabled and it's catching up. > > Cheers, > Rob > -- Diogo M. Matsubara _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
